Every organization has a system everyone complains about and nobody replaces. The reason is not loyalty. It is that the last migration took eight months, ate a summer, and left half the data behind, so the memory of switching is worse than the daily cost of staying. That memory is usually accurate about the pain and wrong about the cause.
The costs nobody puts in the comparison spreadsheet
When teams evaluate a switch, they compare subscription prices. That is the smallest and most predictable number in the whole exercise. The costs that decide whether a migration succeeds are almost never on the sheet.
| Cost | Typical size | When you feel it |
|---|---|---|
| Subscription difference | Small and predictable | Monthly, forever |
| Data cleanup and mapping | Days to weeks of staff time | Before you can start |
| Parallel running | Two systems, two sets of habits | The transition window |
| Retraining | Hours per person plus a slow month | First 60 days after cutover |
| Rebuilding integrations and reports | Often the largest single item | Discovered late, usually |
| Institutional memory loss | Hard to quantify, real | Six months later, when someone asks for history |
Set against that, the cost of staying is equally real and even less visible: the hours spent re-keying between disconnected tools, the reports that take a day to produce, the questions nobody can answer, and the workarounds new staff inherit as if they were policy. Both numbers deserve to be written down before the decision.
When switching is genuinely worth it
Not every complaint justifies a migration. These are the situations where staying costs more than moving, in roughly the order of how often they turn out to be decisive.
- The system cannot hold something central to your work. Not inconvenient, cannot. You are keeping a parallel spreadsheet for something the system should own.
- You are paying for four tools that overlap. Subscription creep is the visible symptom; the real cost is the re-keying between them and the fact that no single record is trusted.
- You cannot get your own data out. If export is limited, deliberately awkward, or requires a support ticket, the lock-in will only tighten with time.
- Growth has outrun the model. The system was built for one location, one program, or five people, and you are structurally past that.
- Support has degraded past a threshold. Unanswered tickets on billing or data issues are a business risk, not an annoyance.
Reasons that usually do not justify a switch on their own: the interface looks dated, one feature is missing that a workaround already covers, or a new staff member preferred a different tool at their last job. Those are real preferences, but they rarely survive contact with the true cost of migration.
If you cannot export your data cleanly, you are not choosing whether to switch later. Someone else already chose for you.
The sequence that keeps it to one quarter
Migrations that run for a year almost always tried to move everything at once and did the data cleanup inside the new system. Reverse both of those and a typical small organization can be fully moved in eight to twelve weeks.
- Export everything first, before you commit. Pull a full export from the current system in week one, whatever your decision ends up being. It tells you what you actually have, it reveals export limits while you still have leverage, and it is your safety net if anything goes wrong later.
- Clean the data outside both systems. Deduplicate, standardize, and fix the obvious errors in a spreadsheet before import. Cleaning inside the new system is slower, and it teaches your team that the new system is full of bad data on day one.
- Decide what does not come with you. Archive rather than import: inactive records past a cutoff, dead projects, ancient transactions. Keep the export as your historical archive and move only what is live. This one decision removes more time than any other.
- Map the fields explicitly, in writing. A simple two-column document: old field, new field. This is where you discover the three custom fields that hold critical information nobody documented, and it is much better to find them now than during import.
- Move one function completely, not everything partially. Pick the function with the cleanest data, often people or contacts, and move it fully. A finished piece builds confidence; five half-moved functions create a period where nobody knows which system is authoritative.
- Set a hard cutover date per function, and enforce it. Parallel running is the single biggest source of migration pain. Announce the date, make the old system read-only that day, and hold the line. Indefinite parallel running is how a migration becomes permanent.
- Rebuild reports last, from real data. Reports built during migration get rebuilt anyway once real data lands. Wait until a function is live and stable, then rebuild the handful of reports people genuinely use, which is usually far fewer than the number that existed.
The mistakes that turn a quarter into a year
- Importing everything because it is there. Every record you carry is a record you clean, map, verify, and later search past. Archive aggressively.
- Running both systems indefinitely. Without a hard cutover, staff use whichever they prefer, data splits, and neither system is trustworthy.
- Migrating during your busiest season. Move during your quietest window, even if it means waiting a quarter. A migration during peak season fails and takes the season with it.
- No named owner. Migrations run by committee stall at every ambiguous decision. One owner with authority to decide what gets archived is essential.
- Skipping the training week. A system nobody was taught becomes a system people work around, and the workarounds become the new normal within a month.
- Not documenting the new process. The migration is the rare moment when writing the SOP is easy, because everyone is thinking about the process anyway.
Protect yourself in the next system
Whatever you move to, assume you might move again in five years. The point is not disloyalty, it is that portability is the only real protection against a vendor decision you do not control.
- Test the export before you sign. Ask for a full export of a trial account. What comes back tells you more about the vendor than any sales conversation.
- Check whether the export includes attachments and history. Contact lists export from everywhere. Documents, notes, and transaction history are where lock-in actually lives.
- Confirm the ownership language in the contract. Who owns the data, what happens at termination, and how long you have to retrieve it.
- Keep your own periodic backup. A quarterly export stored somewhere you control turns a vendor outage or dispute from a crisis into an inconvenience.
- Prefer fewer systems. Every additional tool is another migration you will eventually face, and another seam where data goes stale.
Key takeaways
- The subscription difference is the smallest cost. Cleanup, retraining, and rebuilt reports are the real numbers.
- Switch when the system cannot hold something central, when tools overlap expensively, or when you cannot export your data.
- Export first, clean outside both systems, and archive rather than import anything that is not live.
- Move one function completely with a hard cutover date instead of running everything in parallel.
- Test the export of the new system before signing, and keep your own quarterly backup afterward.
Common questions
How long should a migration actually take?
For a small organization with clean-ish data, eight to twelve weeks is realistic when you move function by function. Larger organizations with multiple locations and heavy integration work should plan two quarters. Anything projected beyond that is usually a sign that the scope includes work that should be archived rather than migrated.
Should we pay the new vendor to do the migration?
Paid migration help is worth it for the import mechanics and field mapping. It is not a substitute for your own data cleanup and archiving decisions, because only your team knows which records still matter. Buy the technical work, keep the judgment in house.
What do we do with the old system after cutover?
Keep it in read-only mode for one full cycle of your business, typically a year, so anyone can retrieve historical detail. Take a complete export at cutover and store it somewhere you control, then cancel. Paying for a live seat indefinitely because nobody trusts the archive is a common and avoidable expense.
How do we handle staff who resist the change?
Most resistance is a rational response to losing hard-won proficiency. Name that directly, invest in the training week, and pick a few respected people to learn it first so peer help is available. Resistance that persists past sixty days is usually about a genuine workflow gap worth investigating rather than an attitude problem.
Is it ever right to stay on a system everyone dislikes?
Yes, when the complaints are about interface preference rather than capability, when you are inside your busiest season, or when a migration would land on a team already absorbing a major change. Staying is a legitimate decision. Making it deliberately, with the cost of staying written down, is what separates it from avoidance.
