Quick answer: Custom software replacement takes most service businesses 90 to 180 days from decision to cutover. Projects that finish on time share the same six moves: audit the old system, freeze scope, map data and integrations, run both in parallel, switch one workflow at a time, and decommission the original. Skip any step and the migration either stalls or ships broken. Here is the playbook that keeps it boring.
Why Every Custom Software Project Has a Sunset Date
The custom dispatch board you built in 2019 worked. It solved a real problem, replaced a spreadsheet that was killing you, and gave your team something they could actually use. Then the developer who built it took a job somewhere else. Then the third-party API your software called changed its pricing. Then your service area expanded and the routing logic no longer fit. Three years later, you have a tool the business cannot run without and no one is fully sure how it works.
This is the most common reason service businesses call us. Not "we want new software." It is "we cannot stay on this software." The custom app that solved one problem has become the next problem.
The good news is that sunsetting a custom system is a solved problem. The same six-step playbook works whether you are migrating to a SaaS platform, replacing it with another custom build, or consolidating onto a single core tool. What changes is the destination. The path does not.
The Six Signals Your Custom Software Has Reached End of Life
You can argue about any single signal. You cannot argue about all six showing up at once.
| Signal | What it looks like in your business |
|---|---|
| The original developer is gone | No one on your team or contractor side can confidently ship a fix in under a week |
| Security patches are overdue | OpenSSL, Node, or framework updates have not run in 12+ months and the system touches customer data |
| The integration list is a graveyard | API endpoints you depend on are deprecated, sunset, or have changed pricing in a way that breaks your unit economics |
| Every change requires a freelancer | New feature requests cost $3,000 to $15,000 and take 4 to 8 weeks, even when they are small |
| Customer workarounds are multiplying | The team has built spreadsheets, Zapier zaps, or Notion pages that exist only to patch holes in the main tool |
| The data model no longer fits | Your service lines, pricing structure, or territory map has changed enough that the original schema fights every report |
Two of these alone are survivable. Four or more, and the replacement conversation moves from "if" to "when." At AnovaGrowth, we have not seen a custom system with all six signals stay in production for more than another 18 months without a major incident.
Operating note from the field: The most expensive signal is the developer who left. Not because of the loss of code, but because the institutional knowledge of why a specific field, table, or workflow exists is gone. That is the signal that quietly doubles every estimate for the next migration.
The 90-Day Migration Playbook
This is the playbook we use on real projects. Each step has a fixed window. You can compress the early ones, but the parallel run and cutover windows should not move.
Step 1, Days 1 to 10: Audit the Old System
Before you choose a replacement, you need an honest picture of what the old system actually does. Most owners guess here, and the guess is always wrong in the same direction: they underestimate by 30 to 50 percent.
The audit answers four questions:
- What data lives in the system? Every table, every field, every record count, plus where the data goes (CSV exports, API calls, downstream reports).
- What workflows run through it? List every process that touches the tool, in plain language. "When a job closes, a tech gets paid." "When a customer calls, the system pulls up their last three jobs." Write them like user stories.
- What integrations does it depend on? Every third-party API, webhook, OAuth connection, scheduled job, and file drop. Note which ones are still active and which have rotted.
- Who uses it and how often? A usage map by user, by feature, by hour of day. This is what tells you what actually has to keep working on day one of the new system.
The output is a one-page inventory. If you cannot fit the audit on one page, the system is more complex than you thought, and the migration needs a longer runway.
Step 2, Days 5 to 15: Freeze Scope
Every migration dies because the new system becomes a wish list. A team that needed a CRM replacement suddenly also wants a new reporting layer, a client portal, a mobile app, and a pricing engine. The project balloons from 90 days to 18 months and ships nothing.
The freeze rule is simple: the replacement must do everything the old system did, no more and no less, on day one. New features go on a roadmap for the 90 days after cutover.
If a stakeholder pushes back, point them at the audit. The audit is the contract. Anything not in the audit is out of scope for the migration.
Step 3, Days 15 to 35: Map Data and Integrations
Data mapping is the step that decides whether the migration ships on time or blows up. Most projects underinvest here.
For each table in the old system, you need three artifacts:
- A field-by-field mapping to the new system. Where there is no clean match, write a transformation rule.
- A data quality report for the source. Duplicates, missing fields, orphan records, and inconsistent formats should be cleaned before the cutover, not after.
- A test record set of 100 to 500 rows that the team reviews manually. If the team cannot read the records and recognize them as customers, jobs, or invoices, the mapping is wrong.
Integrations get the same treatment. For every webhook or API call, document the trigger, the payload, the destination, and the failure mode. If the new platform does not support a required integration natively, you need a custom connector, and that connector needs its own mini-spec.
Step 4, Days 30 to 60: Run Both Systems in Parallel
This is the step that makes the rest of the project work. From day 30 onward, both systems run at the same time. The old system stays the source of truth for a small set of workflows; the new system becomes the source of truth for the workflows being migrated; nothing critical touches only the new system until the cutover.
The parallel run is not optional and it is not a luxury. It is the only honest way to find the edge cases the audit missed.
What to watch for during the parallel run:
- Record mismatches. When the same job, customer, or invoice exists in both systems, do the numbers match? When they do not, which one is right?
- Integration failures. Webhooks fire twice, API calls time out, scheduled jobs skip. Document every failure with the timestamp, payload, and resolution.
- User behavior. Are people actually using the new system, or are they still logging into the old one because the new one feels slower or unfamiliar?
At AnovaGrowth, we treat the parallel run as the real test. If the new system cannot survive two weeks of real traffic with the old system watching, it is not ready for cutover.
Step 5, Days 60 to 80: Switch One Workflow at a Time
Cutover happens in slices, not in a single weekend. Pick the lowest-risk, highest-volume workflow and switch it first. For most service businesses that is one of these:
- New lead capture (form, phone, chat) into the new CRM
- Job scheduling and dispatch into the new system
- Invoicing and payment posting into the new platform
- Customer communication (reminders, confirmations, follow-ups) from the new system
Run that single workflow on the new system for one week with the old system still active as a backup. Then switch the next workflow. Continue until every workflow has been migrated, one slice at a time.
The temptation to flip everything on a Saturday is real. Resist it. The slice-by-slice approach turns a single high-risk weekend into a series of small, recoverable events.
Step 6, Days 80 to 90: Decommission the Old System
Once the last workflow has been running on the new system for two full weeks without a critical issue, you can shut down the old system. Decommissioning is its own step, not an afterthought.
The decommission checklist:
- Export a final archive of the old database. Store it in cold storage for the retention period your industry requires. For most service businesses that is 7 years for tax and customer records.
- Revoke API keys and OAuth tokens that the old system used. Cut off every active integration.
- Notify users that the old system is read-only or offline. Do this in writing, with a date, in advance.
- Cancel hosting, domains, and vendor contracts. Most of these have annual terms. Know the cancellation date before the project starts so the savings show up in the post-cutover financials.
- Document the lessons. What the audit missed, what the parallel run revealed, what the team wishes they had known. The next migration will be easier because of this writeup.
Proof point: On a recent HVAC replacement project, decommissioning on day 92 freed up $840 per month in legacy hosting and licensing the owner had been paying for two years without realizing. The new platform cost $420 per month, so the net savings were $420 per month, or $5,040 per year, before counting the team hours recovered from the faster workflows.
What Goes Wrong If You Skip a Step
Every migration we have seen go sideways has skipped one of the steps above. The failure pattern is predictable.
| Skipped step | What happens next |
|---|---|
| Audit | The team discovers a critical workflow on day 60 of cutover. The project restarts, blowing the timeline by 8 to 12 weeks |
| Freeze | Scope creep adds three new features. The migration slips to month 6 or month 9 with nothing live |
| Data map | Records do not match. Customers see wrong job history, techs see wrong pay, accounting closes the month on bad numbers |
| Parallel run | A load-bearing integration fails in production. The business reverts to the old system and trusts the new one less than before |
| Slice cutover | A big-bang weekend cutover goes well until day 5, when an unmonitored workflow breaks and nobody notices for two weeks |
| Decommission | The old system stays running in the background, costing $300 to $1,500 per month forever, because nobody wants to be the person who turns it off |
The six-step pattern is not theory. It is the shape every successful replacement we have run has followed, regardless of industry or platform.
How AnovaGrowth Runs a Replacement Project
When a service business brings us in for a replacement, the engagement is fixed-fee, scoped to the six steps above, and runs 90 days from kickoff to decommission. We do not own the new platform choice. That decision belongs to the owner, with our input on fit, total cost, and integration coverage.
What we own is the audit, the data mapping, the parallel run, and the cutover plan. We run the parallel run alongside the owner's team so the people who will use the system every day are the ones testing it. That is the part most projects skip, and it is the part that decides whether the new system gets adopted or quietly abandoned.
Our custom software scoping guide covers the build side of the same problem. The replacement playbook is the flip side: how to get off custom software cleanly when it has run its course.
If you are at the start of the journey (deciding whether to build or buy), the CRM data migration playbook walks through the data layer in detail. The replacement playbook above assumes you already have that data layer mapped.
Common Questions Service Business Owners Ask About Replacement
How long does a custom software replacement really take? Ninety days is the floor for a focused migration on a single core platform. If the old system is large, has multiple integrations, or runs critical revenue workflows, plan 120 to 180 days. The bottleneck is almost always the parallel run, not the build.
What is the realistic cost of a replacement project? For a service business replacing one core platform with another, plan $25,000 to $80,000 for the migration work, separate from any new platform licensing. The range depends on data volume, integration count, and how much customization the old system has accumulated.
Can we replace the software in-house without a partner? Sometimes. If the team has run a SaaS migration before, owns the data mapping, and has the parallel-run discipline, in-house works. If the team is learning the steps while running them, a partner pays for itself by avoiding the second attempt most failed migrations require.
What is the biggest hidden cost in a replacement? User adoption. A new system that the team avoids is more expensive than the old system they hated, because you pay for both. The parallel run is the cheapest place to surface adoption risk. If users are not logging in during the parallel window, they will not log in after cutover.
When should we just keep the old custom software? When only one or two of the six signals above are present and the rest of the system is stable. A targeted modernization, not a full replacement, is the right call in that case. The replacement playbook is for systems with four or more signals, or with a critical signal like a missing developer or a deprecated API.
Key Takeaways
- Custom software replacement is a six-step project, not a single weekend. Treat it like one.
- The audit is the most important artifact. If you cannot fit the system on one page, you do not yet understand what you are replacing.
- The parallel run is the only honest test of the new system. Plan at least 30 days for it.
- Slice-by-slice cutover beats big-bang cutover every time. Small, recoverable events beat a single high-risk weekend.
- Decommissioning is a real step. The cost savings show up there, not in the new platform license.
- If the old system has four or more end-of-life signals, the question is not whether to replace it. The question is which quarter of the next 12 months you want it done in.
Ready to plan a replacement? Contact us to scope a 90-day migration on the system you need to leave behind. We will run the audit, map the data, and hand back a fixed-fee plan before you sign anything.
