blog

A Platform Migration Never Costs What the Proposal Says

Written by Nick Stevens | Nov 10, 2026, 5:00:01 PM

The vendor's quote is the easy part. The real cost of switching platforms shows up in your people's time, your data, and the weeks after launch. 

TL;DR: The number on a migration proposal is real, but it's rarely what a firm ends up paying. Most of the cost shows up later, in staff pulled off client work to run the project, weeks of paying for two systems at once, data that needs serious cleanup before it can move, and a team that takes a while to get back up to speed. McKinsey has found that migration spending typically runs about 14% over plan each year, and more than a third of companies see delays of a quarter or longer. Getting all of that on paper before signing gives partners a figure they can trust and keeps billable time from disappearing into a project nobody planned for. 

 

Every platform migration starts with a quote. It's usually on the last page of the proposal, covering licenses, setup, and a neat block of training hours. Partners compare it against how frustrating the current system has become, and the decision starts to feel easy.

It's a lot like adopting a puppy. The adoption fee is reasonable, maybe even a bargain, and you head home with a leash and a bag of food. Then come the vet visits, the obedience classes, the chew toys that don't last the week, and the couch cushion that didn't either. Nobody regrets the puppy. Nobody who's owned one thinks the adoption fee was the real price, either.

A new practice management, document, or billing platform works the same way. The vendor can tell a firm what the software will cost. What the move will cost is a different figure, and most of it falls on the firm's own people and calendar. With 2027 plans taking shape, that's the figure partners need most.

Migrations are also getting more involved. Firms run more connected tools than they did five years ago, clients expect tighter security around their data, and vendors keep steering customers toward cloud versions of software they've used for a decade. Every one of those shifts adds work that never makes it onto a quote.

A migration can still be the right move. It just goes a lot better when the firm knows the full cost going in, instead of discovering it one invoice at a time.

Table of Contents

  1. Why the Quote Is the Smallest Number in a Migration
  2. Running Two Systems at Once
  3. Data That Has to Be Cleaned Before It Can Move
  4. Integrations, Workarounds, and the Slowdown After Go-Live
  5. Building the Real Budget for a Migration
  6. The Adoption Fee Was Never the Expensive Part
  7. Key Takeaways
  8. Frequently Asked Questions

Why the Quote Is the Smallest Number in a Migration

A vendor can only price what the vendor controls. Licenses, a setup package, and a block of training sessions fit nicely on a proposal. What the project takes from your own people doesn't, so it usually isn't there at all.

That's not a knock on vendors. They have no idea how clean your data is or how long testing will take. But in our experience, the license is rarely the expensive part. The hours are. Somebody has to run the project, test every workflow, sign off on the setup, and keep everybody else in the loop, and at a professional services firm, those hours come straight out of client work.

Even the big players get this wrong. McKinsey estimated that overruns and delays would waste around $100 billion in migration spending over three years, and those were companies with whole teams dedicated to the project. A 40-person firm doesn't have that kind of cushion.

So before anyone starts comparing features, ask whether the move still makes sense once everyone's time is counted. We ask that about our own tools now, mostly because we've learned what happens when nobody does.

And if you're still deciding whether to replace the system at all, start with our look at why new software can't fix a process that's broken or was never there.

Running Two Systems at Once

Very few firms get to flip a switch on Friday and start fresh on Monday. Most of the time, you're running the old platform and the new one side by side for a few weeks or months, paying for both, entering some things twice, and chasing records that don't quite match.

Skipping that stretch looks like an easy way to save money. It isn't. Without it, the new system's first real test happens on live client work, and every hiccup becomes your client's problem. The whole point of a careful cutover is keeping the business running normally while everything changes underneath it.

The overlap needs a referee, too. Somebody has to decide which system is the source of truth for each task and make sure everyone knows it, or you'll end up with time entered in one platform and matters opened in the other. Set a firm cutoff date and stick to it. Two extra weeks of double licensing is a rounding error. Two extra months of people checking both systems for the same client file is not.

Data That Has to Be Cleaned Before It Can Move

Ask anyone who's been through a migration where things got messy, and there's a good chance they'll say the data. Duplicate contacts, a matter-naming system that changed three office managers ago, fields nobody has touched since 2019, and a decade of closed files all have to be sorted before they move. Skip that step, and the new platform looks just as cluttered as the old one on day one. Guess which system gets the blame.

That clutter isn't a small-firm quirk, either. Gartner puts the cost of poor data quality at $12.9 million a year for the average organization it studied. Your firm's number is a lot smaller, but you'd recognize the symptoms. Searches drag, reports don't add up, and people start keeping their own spreadsheets on the side because they've stopped trusting the system.

Some data matters more than the rest. In a professional services firm, document metadata has to come across intact, or nobody can find anything. Billing and trust accounting records have to reconcile to the penny. And conflict-check data has to be complete, because a missing record there can turn into an ethics problem fast.

Then there's mapping, which is less exciting than it sounds, and it doesn't sound exciting. Every field in the old system needs a home in the new one, and they almost never line up. Somebody has to decide what gets merged, what gets archived, and what you can finally let go of. We'd much rather have those conversations around a conference table a month out than at 9 p.m. the night before cutover. And please, back everything up and test the restore before anyone touches a thing.

Integrations, Workarounds, and the Slowdown After Go-Live

Most platforms don't live on an island. Yours is probably wired into email, calendars, accounting, e-signature, intake forms, and document storage, and every one of those connections has to be rebuilt or replaced. Some will work out of the box. Others will need a developer, a middleware tool, or a new subscription nobody saw coming. Make a list of every connection early, including the one only accounting uses, because the forgotten integration is always the one that breaks on launch day.

Then there are the workarounds. Over the years, your people have built their own fixes for whatever the old system never did well. Maybe it's a spreadsheet tracking deadlines, or a saved search that only one paralegal knows how to run. None of that migrates, because it was never officially part of the system. If nobody writes it down first, it just vanishes, along with whatever it was holding together.

And expect a slowdown. Even a smooth launch costs a few weeks of productivity while people learn new screens and break old habits. That's normal. Just don't go live during year-end billing or the week before a big trial, and think about starting with one practice group before rolling out to everyone.

How well your team takes to the new platform after launch decides whether any of this spending pays you back, and that's the subject of an upcoming post on why expensive new software so often ends up as shelfware.

Building the Real Budget for a Migration

Once those hidden lines are out in the open, the budget looks a lot different. A realistic migration estimate usually covers:

  • Licenses and implementation, the part already in the proposal
  • Your people's time, including a project lead with real hours set aside
  • Overlap for running both systems during the switch
  • Data cleanup and mapping
  • Integration work and any new tools it drags in
  • Training that keeps going after launch week
  • A productivity cushion for the first few weeks
  • Contingency, because something always comes up

You won't nail every line to the dollar, and that's fine. The goal is a number next to every category, so when partners compare options, they're looking at the whole cost instead of the slice the vendor quoted.

It's also fair to push the vendor a little. How many migrations like this have they done for firms of your size, and can you talk to one of those firms? How many hours will they need from your staff? Which integrations work today, and which are still "on the roadmap"?

Sometimes the full number confirms the move. Sometimes it tells you to spend next year getting more out of the system you already have. Holding on longer comes with its own costs, especially once a system is past its support date, and a later post in this series looks at how to manage that risk while a replacement waits.

The Adoption Fee Was Never the Expensive Part

So here's where it all lands. The quote covers the software. Everything else lands on the firm, including the hours your people put in, the weeks of keeping two systems alive, the data that has to be scrubbed, the integrations that need rebuilding, and the dip after launch. That doesn't mean you should stay put. It means you should know what you're signing up for, the same way you'd want to know before bringing a puppy home.

And if you've been through a migration before, you probably remember how it went. The project that was supposed to take a quarter took three. Half the matter history showed up missing. People spent months asking how to do things they used to do without thinking, and somewhere along the way, the partners started wondering whether the old system was really that bad.

We've been on both sides of this, as the team running the migration and as a business that picked the wrong tool and lived with it. That's shaped how Heroic Technologies handles migrations now. We start with the full cost, clean and map the data, rebuild the integrations, run the cutover, and stick around while your team settles in. And if the numbers say a migration doesn't make sense yet, we'll tell you that, too.

If a new platform is on your 2027 list, get in touch with Heroic Technologies and let's put a real number on it. The puppy is always worth it. It just helps to budget for it.

Key Takeaways

  • A proposal shows what the software costs, while the move itself costs far more.
  • The biggest hidden expense is your people's time, and it comes out of client work.
  • A short, well-managed overlap protects clients during the cutover.
  • Clean and map your data before it moves, and test the backup first.
  • Find integrations and homegrown workarounds early, before launch day exposes them.
  • Sometimes the full number says to get more out of the system you already have.

Frequently Asked Questions

1. What are the hidden costs of a platform migration?
The biggest one is your own people's time, because someone has to run the project, test everything, and keep the firm informed while still serving clients. After that come the weeks of paying for two systems, the data cleanup, the rebuilt connections to tools like email and accounting, and the slowdown while everyone gets comfortable. None of it shows up on a typical vendor quote, so it's on you to estimate it.

2. What are the biggest data migration risks for a professional services firm?
The scariest ones involve records that have to arrive complete, like document metadata, billing, trust accounting history, and conflict-check information. Messy or duplicate data is the other big risk, because it makes the new system look unreliable from day one. A verified backup, a clear plan for what moves and what gets archived, and real testing before cutover take most of the sting out.

3. How long does a platform migration usually take?
Longer than the sales demo suggests. For most firms, moving a practice management or document system takes a few months from planning to the point where everyone's comfortable, including a stretch of running both systems. Rushing it usually just moves the problems into live client work, so building in time for cleanup, testing, and training tends to save time in the end.