Designing IT for the 30th of January

A normal-week practice has comfortable headroom. The practice management system responds quickly, the document portal handles inbound uploads without queueing, and email volumes are predictable. Everything looks fine.

Then traffic triples. Twenty fee-earners are pushing returns through the practice management system simultaneously. Clients are uploading documents to the portal at midnight. The mailbox is receiving signed engagement letters faster than anyone can file them. The system is the same. The load isn't.

Bottlenecks that didn't matter in November become hard limits in late January. Database contention, portal throughput, mailbox indexing, network upload at the office: any of these can produce the experience of 'everything is slow and I don't know why'.

Practice management software performance under concurrent load. Most firms have never tested this deliberately. A simple exercise of forty people doing realistic tasks at the same time, ideally in November, reveals more than a year of vendor briefings.

Mailbox response times when the inbound volume triples. Microsoft 365 handles this gracefully at the platform level, but anti-spam systems, mail relays and on-premise archiving solutions don't always. Find that out before it matters.

The document portal's ability to handle clients uploading at the last minute. A surprisingly common failure mode is the portal not scaling well during the final 48 hours, with uploads queuing or timing out. The portal vendor's 'fair use' policy gets quietly invoked, and you find out via clients ringing in.

VPN capacity if anyone is still relying on it for hybrid working. VPN concentrators have hard limits. They get hit in late January more reliably than the practice management system does.

Mature firms run a change freeze from mid-November through early February. No upgrades, no migrations, no new tools, no fiddly configuration changes. The platform you have in November is the platform you take through busy season.

Change freezes feel restrictive, and they catch a few useful improvements that get delayed. They also catch the upgrade that would have gone wrong on the 25th of January, and that one save justifies the freeze on its own.

Busy season is the worst time to lose data. It's also the time you're most likely to need it: a corrupted database, an accidental deletion, a ransomware event aimed at finance-adjacent firms.

A pre-season check on backups is non-negotiable. Not 'is the backup configured', but 'have we restored from it in the last quarter, and how long did it take?' A backup you've never restored is a hopeful diagram.

Pair that with a clear answer to 'what happens if the practice management system is unavailable for two hours on the 28th of January?' Most firms haven't thought it through. The ones who have can keep working in a degraded mode while the system comes back.

If you have a managed IT partner, they need to plan for your busy season too. A partner who's never been told that 30th January matters will treat a P2 ticket on the day with normal urgency. A partner who knows will flex their roster, prioritise your queue, and have an engineer on standby.

This is a conversation, not a contract clause. The good partners will already have it on their calendar; the rest need a polite nudge in October.

Clients are the other variable. A clean, low-friction document portal with clear instructions removes most of the inbound chaos. A messaging template for clients who try to submit at 23:50 on the 31st keeps the conversation civil.

Some firms now actively promote a 'submit by the 20th' campaign through November and December. Even a small shift in the distribution of inbound work reduces peak load materially.

A busy season that passes without a P1 of your own making. The practice management system is responsive. The portal handles the late surge. Email is fine. The partner relationship is intact, the team is tired but proud, and nobody is talking about IT at the post-season review.

That's the goal. The work to get there is done quietly between September and November, and it's some of the highest-leverage IT spend a practice ever does.

Most practices do a post-season review of the work. Fewer do a post-season review of the platform. The questions are different and equally useful: what went wrong technically, what was almost a problem, what would we want different next year, and what should be on the September pre-season list?

Capturing this within a fortnight of the deadline, while it's fresh, produces a much better set of priorities than waiting for the year-end planning cycle. Most of the items are small, cheap and high-leverage, and they compound year on year into a busy season that gets quieter rather than louder.