Most firms that migrate off spreadsheets and email do not do it because they wanted to. They do it because a document went missing somewhere in a long forwarded chain, a deadline was tracked in a workbook two people were editing at the same time with no version control, or a new hire spent their first week guessing which of forty open tabs was actually the current one. The problem is that by the time the pain is bad enough to force a decision, the firm has live jobs, live deadlines and live clients mid-engagement, and a clumsy migration risks doing more damage in a fortnight than the spreadsheet ever did in a year.
This is a practical plan for moving a firm from spreadsheets and email onto a proper client portal and practice management system without a single client noticing a dropped ball along the way. It assumes you have already chosen a platform; if you have not, work through a fair evaluation checklist first, because the plan below only works if the destination is actually capable of holding what you are about to move into it.
Why a Big Bang Cutover Fails
The instinct is to pick a date, export everything over a weekend, and switch the whole firm across in one go. In practice this almost always fails for one specific reason: the spreadsheet and the inbox contain information that exists nowhere else, half-remembered context from a call three months ago, a verbal agreement with a client that was never written down anywhere, a document attached to an email that nobody thinks to re-upload because nobody remembers it exists. A single cutover date compresses all of that discovery work into forty-eight hours, which is exactly when mistakes happen and exactly when clients are most likely to notice something has gone wrong.
A staged migration, run over four to six weeks depending on firm size, spreads that discovery work across a period where staff can still fall back on the old system if something turns out to be missing, while steadily and deliberately reducing reliance on it week by week rather than all at once.
There is also a psychological dimension to this that is worth naming plainly. Staff who have worked a particular spreadsheet for years have genuine, well-earned expertise in its quirks, they know which tab actually matters, which formula is broken, which colour coding means what. A big bang cutover discards that expertise overnight and replaces it with nothing, which is precisely why staff quietly resist migrations that move too fast: not out of stubbornness, but because the new system genuinely has not yet earned the trust the old one built up over years of daily use. A staged approach lets that trust transfer gradually, one successful week at a time, rather than demanding it be granted on faith from day one.
Phase 1: Audit Before You Touch the New System
Before creating a single client record in the new platform, audit what actually exists. List every client, every active job, and every document that needs to move, and be honest with yourself about where each one currently lives, because this step is tedious and firms are tempted to skip it straight to the exciting part, which is precisely why skipping it is the step that causes the worst migration failures. Cross-check every upcoming deadline against Companies House and, for UAE clients, the FTA compliance calendar directly, rather than trusting whatever a spreadsheet says, since spreadsheets drift out of date the moment two people stop maintaining them with equal discipline.
This is also the moment to flag which documents exist only as email attachments and have never been saved anywhere else. Those documents are the ones a migration most commonly loses, not because anyone is careless but because nobody thinks to look for them until a client asks for something specific and it turns out to have vanished into an old thread six months earlier.
Assign one named owner for the audit itself, ideally someone detail-oriented rather than whoever is least busy that week, because a rushed audit produces a false sense of completeness that only becomes visible weeks later when a gap surfaces at the worst possible moment. Budget genuinely more time for this phase than feels necessary. Firms that treat the audit as a formality to get through quickly are consistently the ones who discover the most painful gaps mid-migration, precisely because the audit was the one phase built to catch them before they became live problems.
- Export a clean client list from wherever it currently lives, even a messy, inconsistently formatted spreadsheet
- List every job or engagement currently in progress with its actual current status, not its status as of the last update
- Cross-check every deadline in the next ninety days against Companies House or the FTA calendar directly
- Flag which documents exist only in email attachments and have never been saved anywhere permanent
- Assign one named owner for the audit who is accountable for its completeness, not whoever has spare time
Phase 2: Build the Client Records First, Work Second
Import or manually create every client record in the new system before migrating a single active job. For UK clients, a Companies House lookup by company number or name should populate registered details automatically rather than requiring re-typing, which both saves time and removes the transcription errors that inevitably creep in when a registered address gets typed out by hand for the tenth time that afternoon. For firms using a CSV import, build the template with exactly the fields the audit surfaced, business name, entity type, primary contact, email and Companies House reference number where applicable, and import in one clean, deliberate pass rather than trickling records in over several weeks, since half-migrated states are far easier to lose track of than a firm expects.
Resist the temptation to migrate historical closed jobs at this stage. Historical data can be brought across later, calmly, once the firm is running live in the new system on current work. Trying to bring five years of closed engagements across at the same time as live, deadline-driven work multiplies the risk for essentially no immediate operational benefit.
For UK clients specifically, run the Companies House lookup for every single client during this phase rather than accepting whatever address or entity name happens to sit in the old spreadsheet. Registered details drift more often than firms expect, a company moves premises, changes its registered name slightly, or updates its SIC code, and none of that reliably makes its way back into a spreadsheet that someone updates by hand only when they happen to remember. Treating the migration as an opportunity to refresh every client's statutory data against the live register, rather than simply copying across whatever was last typed in, meaningfully improves the accuracy of the client base going into its first year on the new platform.
Phase 3: Move Jobs in Waves, Then Bring Clients In Gradually
Split active jobs into two or three waves based on urgency and complexity. Move the simplest, lowest-risk jobs first, a handful of routine bookkeeping or VAT engagements with no imminent deadline, so the team learns the new system's job creation and Smart Board workflow on genuinely low-stakes work before anything time-sensitive depends on them knowing what they are doing. Once that first wave is comfortably running, move the next wave, and deliberately hold back anything with a deadline inside the next two weeks until the team has proven the workflow to themselves on less urgent work first.
Clients should not all receive a portal invitation on the same day either. Stagger portal onboarding client by client, starting with the ones most likely to adopt it smoothly, generally the more digitally comfortable clients or those already visibly frustrated with the old email back-and-forth. Send a short, warm invitation explaining precisely what changes for them: where they will now find their documents, how they will now message the firm, and that email is no longer the primary channel for sensitive material. For the first few weeks of a client's portal life, keep watching their old email thread as well as their new portal messages, rather than assuming the switch is complete the moment the invitation goes out, because some clients will keep replying to the old thread out of habit for a while, and someone needs to see that and gently redirect them.
- Invite clients in small batches of five to ten per week, never all at once
- Send a short explainer with every invitation: what moved, where to find it, who to contact if stuck
- Monitor the old email inbox in parallel for at least four weeks per client cohort
- Track portal login rates and follow up personally with anyone who has not logged in after a week
Phase 4: Retire the Spreadsheet, Deliberately and on a Date
The single most common migration failure is not the move itself, it is that the old spreadsheet quietly keeps being updated by one or two staff members out of pure habit, long after the firm has declared the migration officially complete. Six months later the firm discovers two sources of truth disagreeing with each other on a client's status, and nobody can say with confidence which one is actually right.
Set a firm, clearly communicated date on which the spreadsheet becomes read-only, and actually make it read-only, protect the file or move it into an archive location that is not the shared-drive shortcut everyone already has memorised on their desktop. Do this only after at least one full deadline cycle has run successfully through the new system, so the team has real evidence the new platform holds up under genuine pressure before the old safety net is removed for good.
What Not to Migrate, and How to Handle the Inevitable Gaps
Not everything in the old spreadsheet deserves a home in the new system. Stale leads that went cold two years ago, duplicate contact records, and notes that made sense to one person at the time and to nobody since, none of that needs to survive the move faithfully. A migration is a legitimate opportunity to clean house rather than lovingly recreating years of accumulated clutter inside a shinier interface.
Even a careful, well-staged migration will surface gaps, a client whose engagement letter cannot be found anywhere, a deadline that turns out never to have been recorded at all. When this happens, resist the urge to quietly patch it and move on without telling anyone. Log the gap, fix it properly, for a missing engagement letter that usually means reissuing it for a fresh electronic signature rather than assuming an old verbal agreement covers it adequately, and note what process failure allowed the gap to exist in the first place, so the new system's workflow closes that specific gap going forward rather than simply papering over it once.
Measuring Whether the Migration Actually Worked
Do not simply declare victory once every client has an active portal login. Track a small set of concrete indicators over the following quarter: the proportion of client correspondence happening inside the portal versus still arriving by email, the average time between a document being requested and a client providing it, and the number of documents that had to be re-requested because the original could not be located. All three of these should visibly improve within eight to twelve weeks of a well-run migration. If they have not moved, the migration has not actually finished, it has only relocated where the old habits live, and it is worth going back to whichever client cohort or staff workflow is lagging rather than assuming time alone will fix it.
It is also worth asking staff directly, a few weeks in, what they are still doing the old way and why. The honest answer is usually specific and fixable, a particular report they cannot yet produce in the new system, a client who insists on email and has never been formally redirected, a step in the old spreadsheet nobody thought to replicate. Treating that feedback as a punch list rather than as complaining is what closes the final ten percent of a migration that otherwise lingers indefinitely as a half-finished project everyone has quietly stopped talking about.
A Realistic Timeline
For a firm of five to fifteen people with fifty to a hundred and fifty clients, a full migration following this staged approach typically takes four to six weeks from the initial data audit through to spreadsheet retirement, run alongside normal client work rather than as a dedicated project week that pulls everyone off billable engagements. Smaller solo and two-person practices can usually compress this to two to three weeks. The temptation to move faster should be resisted, because the limiting factor here is never how quickly data can be typed into a new system, it is how quickly clients genuinely adapt to a new channel without ever feeling that the relationship itself has been disrupted along the way.
Firms that have been through this migration once tend to describe the same feeling on the other side of it: relief that the discovery work is finally centralised somewhere the whole team can see, rather than scattered across the specific memories and personal inboxes of whichever three people happened to build the old system in the first place. That centralisation, more than any single feature of the new platform, is usually what the firm actually wanted when the migration started, even if the original trigger was something as small as one missing document.
