The license fee is the only number in a system replacement that behaves. It is published, it is per seat, it renews on a date you can put in a calendar. Everything else about the switch arrives later, in a sequence, and mostly from people already on your payroll. Ten years ago that was understood as a project. Now it is often understood as a signup, which is why the surprise lands harder.
The bill arrives in four waves, not one
Wave one is the subscription. Wave two is getting your data out of the old system and into the new one in a shape the new one accepts, which is rarely the shape the export produces. Wave three is the hours your staff spend doing their jobs twice while both systems are live. Wave four is the tail: the reports that no longer exist, the integration nobody documented, the customer who still has a link to the old thing.
Wave three is the one that gets underestimated in every direction. Parallel running is not optional for anything that touches money, and it is not free. If two people spend six weeks entering the same transactions into two systems, you have bought a system and also paid for three months of labor you already had budgeted elsewhere. That is not a hidden cost. It is just a cost nobody puts on the comparison sheet.
What changed in ten years, from where the customer sits
A decade ago, replacing a business system meant a project plan, a server, a consultant with a travel line item, and a go-live weekend. The costs were large and visible. You could see them coming because someone invoiced you for them in advance.
Now the entry cost has collapsed. A department head can put a new system on a card and have it running by Thursday. The implementation cost did not disappear, though. It moved onto your own staff, unpriced, and it moved later in the calendar. The migration you would once have paid a firm to do is now a weekend your office manager spends reformatting a spreadsheet.
Two other things genuinely improved for the buyer. Data export is now expected rather than negotiated, so you are less likely to be held hostage by a proprietary file format. And you can usually run a real pilot with real records before you commit, which was close to impossible when the software arrived on a disc and a purchase order.
The new hazard is scope creep at the small end. A business that once ran three systems now runs eleven, and each one holds a fragment of the record. Replacing the accounting package no longer means replacing the accounting package. It means finding out that the scheduling tool, the payment processor, and whatever the marketing person set up in 2021 all read from it.
The order the work has to happen in
Before you sign anything, inventory what the current system feeds. Not what it does. What it feeds. Every downstream tool, every recurring report, every automated email a customer receives. This is a two-hour job and it is the single cheapest hour in the whole project, because it is the list that determines whether the migration takes three weeks or three months.
Second, run an export from the old system and open it. Do not accept a vendor's word that migration is supported. Look at the file. Check whether attachments came with it, whether historical notes survived, whether the customer records kept their creation dates.
Third, decide what history actually moves. Most businesses move far more than they need and pay for it in cleanup. Live records and open items move. Closed history from six years back can stay archived in a readable format, provided you can still produce it. The IRS is responsible for how long business records must be retained and in what condition they must be produced, and that requirement attaches to the records, not to the software that used to hold them. A readable archive satisfies it. A dead login does not.
Fourth, and only fourth, set the cutover date. Customer-facing pieces should switch last, once the internal work is stable. If you run events and you have been collecting guest images through an aging portal, the replacement is now likely to be something as light as a qr code photo album that guests reach without an account, which is a much smaller migration than the one behind it but still needs the old links pointed somewhere sensible.
Where delay stops being recoverable
You can postpone almost every part of this. You cannot postpone the export past the date your old contract lapses. Once access ends, the negotiating position is gone and the price of retrieval, if retrieval is offered at all, is whatever the vendor decides.
The second hard edge is the fiscal year. A cutover mid-quarter means one set of books in two systems and a reconciliation nobody wants to own. Aligning to a period close costs you a few weeks of waiting and saves considerably more than that.
Price the switch as labor plus a license, not a license plus some inconvenience. Do the inventory first, look at the export with your own eyes, and the rest of it becomes a schedule rather than a discovery.
