Why does replacing the system feel like the answer?
Because every complaint ends with the word system. Billing takes too long. Nobody can find the current version of a document. The management pack is rebuilt by hand each month because the reports do not say what anyone wants to know. Fee earners keep their own lists outside the platform, so the platform is never quite right.
There is also something comfortable about replacement. It is a decision everybody can agree to make. It has a budget line, a vendor, a timetable and a named project. Deciding how the work should actually be done is slow, political and unglamorous. Signing a licence agreement takes an afternoon.
That is the trap. A migration is often the most expensive available way of postponing a decision the partnership does not want to have.
What does a migration actually change?
It changes where the data sits, what the screens look like and which supplier you phone when something breaks. Those are real benefits if the current platform genuinely cannot do what the firm needs: the product is end of life, the supplier has stopped developing it, it cannot export anything usable.
What it does not change is the part that hurts. If three teams raise fees in three different ways, they will do the same in the new system by about month four. If nobody has agreed what a file closure checklist contains, the new system will not supply an opinion. If the real engine of the firm is a spreadsheet somebody maintains on a Friday, that spreadsheet reappears, because it covers a gap nobody has closed. We have written about that habit in the spreadsheet that runs the firm.
Undecided ways of working migrate perfectly. They are the one thing that survives the data cleanse intact.
Where do the eighteen months go?
Very little of it is software. The time goes into selection, reference calls, data mapping, cleaning years of inconsistent records, agreeing the matter taxonomy, configuring permissions, testing, parallel running, training everybody twice, then absorbing the dip in output while people relearn a job they already knew.
Through all of it the firm is distracted. The partners who would have sponsored any other improvement are in requirements workshops. Nothing else gets changed, because changing anything else would complicate the migration. So the write-ups still take as long and the bills still go out late.
Then go-live arrives and the firm has the same processes on better screens, having spent its whole appetite for change on the move.
What is the system getting blamed for?
Take the three complaints most firms raise and test them honestly.
- Billing is slow. Is the software slow, or are narratives written from memory weeks later, then rewritten by a partner who will not sign a bill that reads badly? That is a drafting and review problem. See the bill nobody can raise and invoice preparation.
- Time recording is incomplete. Is the timer hard to click, or is reassembling a fragmented day genuinely difficult? That is a capture problem, covered in timesheet capture.
- Reporting is useless. Is the report writer limited, or has the firm never settled on what it wants to see each month? A new platform cannot decide that either. Board and management reporting starts from the decision, not the dashboard.
The giveaway is variation. When the same job is done differently by different people, you are looking at an unmanaged process, not a product fault, a pattern set out in the variation nobody agreed to.
When is replacement genuinely right?
There are honest cases. The supplier has withdrawn support. Data protection obligations cannot be met on the current platform. Compliance evidence cannot be produced at all, rather than produced slowly. The firm has changed shape and taken on work the system was never designed for.
Note what these share: the answer to "can it do this?" is no, not "not currently configured". If you can reach the outcome with work, you have a process decision. If you cannot reach it at all, you have a product decision. The same logic applies to what you buy against what you build, covered in custom build or off the shelf.
What does fixing one process inside the current system look like?
Pick the single job eating the most time. Sit with the people who do it and write down every input, template, handoff and check, which is the method in how to document a process. Decide the one way it should be done, including who reviews and signs off. Then rebuild it on the firm's own documents and templates, in the tools the team already uses, tested on live work rather than a demonstration.
The advantage is not only speed. It is reversibility. If the rebuilt process is wrong, you adjust it in days. A migration cannot be adjusted in days, and nobody wants to admit it was wrong eleven months in. Starting small is also the only way to learn whether the software was ever the problem.
Give it an owner. The commonest reason a fix decays is that it belongs to everybody and therefore nobody, the subject of the process nobody owns.
How should a firm decide?
Run the test in order. Name the three processes costing the most unbillable time; the unbillable hours calculator will give you a figure. For each, ask whether the current system makes it impossible or merely awkward. If the answer is awkward, rebuild the process and see what is left. Whatever remains is your genuine requirements list, and it beats a wish list written by people describing a system they have never used.
Do it this way and you either avoid a migration you did not need, or enter one knowing exactly what you are buying. The bad outcome is eighteen months, a large invoice and the same working week. The audit will tell you which process to look at first, and what to automate first explains how to rank them.