Many businesses run on a system built years ago: a desktop application, an old web app, a heavily customized package or a set of spreadsheets and scripts. It works, mostly. But it is hard to change, the people who built it have moved on, it does not connect to modern tools and every update feels risky. Over time, this technical debt slows the business down.
Replacing such a system is a significant project. This guide explains how to do it without stopping the business.
Signs it is time
- Small changes take weeks and often break something else.
- It runs on software or hardware that is no longer supported.
- Only one person understands it.
- It cannot connect to the tools the business now needs.
- Security updates are no longer available.
- Staff use workarounds and spreadsheets to fill gaps.
Step 1: Understand what it really does
The old system contains years of business rules, many of them never written down: how discounts are calculated, which customers get special terms, what happens at month end. Before replacing it, document:
- Every screen, report and process people use.
- Business rules, including edge cases.
- Integrations: what it sends to and receives from other systems.
- Data: tables, volumes, quality problems and history that must be kept.
- Who uses it, how often and for what.
Interview users, read the code and watch people work. AI tools can help read and summarize old code, with a developer checking the results. See where AI helps in development and where it does not.
Step 2: Choose an approach
- Improve in place: upgrade, clean up and add tests to the existing system. Right when the core is sound.
- Replace in stages: build the new system alongside the old one, moving one area at a time. The old system shrinks until it can be switched off. Often the safest.
- Replace all at once: build the new system, then switch over in one go. Simpler to plan, but higher risk.
- Replace with a package: adopt existing software and adapt your processes. Right when your needs are standard.
How staged replacement works
A staged approach puts a layer in front of the old system. New features and migrated areas are handled by the new system; everything else still goes to the old one. Area by area, more moves over. Users may not notice the change at all. It takes careful design, but it means each step is small, testable and reversible.
Step 3: Decide what not to migrate
Not everything should move. Unused reports, features nobody needs and workarounds for old limits can be left behind. Each item not migrated saves time and simplifies the new system. Confirm with users before dropping anything.
Step 4: Build the new system
Build with modern, well-supported technology, clear structure and automated tests from the start. Recreate the documented business rules and test them against the old system's results. Build integrations to other systems through clean APIs. See our technology stack.
Step 5: Plan the data migration
Data migration deserves its own plan:
- Map every field from old to new, including transformations.
- Clean data before or during migration: duplicates, missing values, inconsistent formats.
- Write migration scripts and run them repeatedly on copies of real data.
- Check results: record counts, totals and a sample of records compared by hand.
- Decide how much history to migrate and where older data will be archived.
See data migration.
Step 6: Test against the old system
The best test is comparison. Run the same inputs through both systems and compare outputs: invoices, calculations, reports. Differences reveal missing rules or bugs. For critical processes, run both systems in parallel for a period and compare results before switching.
Step 7: Prepare the people
Users need to learn the new system and trust it. Involve key users in testing, provide short training focused on daily tasks and prepare simple guides. Plan extra support for the first weeks after the switch.
Step 8: Plan the cutover
- Choose a quiet time, such as a weekend or after month end.
- Freeze changes in the old system.
- Run the final data migration and checks.
- Switch users and integrations to the new system.
- Verify key processes work end to end.
- Keep the team available to fix problems quickly.
Step 9: Keep a way back
Decide in advance what would make you switch back, and how. Keep the old system available, read-only if possible, until the new one has run smoothly for a period. Know how data created in the new system would be handled if you had to roll back. Having a plan you never use is far better than needing one you do not have.
Step 10: After the switch
Watch closely for the first weeks: errors, support requests and anything that looks different. Keep the old system read-only for reference, then archive its data and shut it down. Document the new system so the knowledge problem that started the project does not return.
How AI helps
AI-assisted development speeds up parts of migration: reading old code, drafting documentation of business rules, writing tests, converting code between languages and writing data mapping scripts. Every output needs review by an experienced developer, since mistakes in business rules are costly. See what is AI-accelerated development.
An example
One of our clients runs a booking system that has served guests for about twenty years. Stopping bookings for a big rewrite was not an option. Instead, the system has been extended and tested while it keeps running, with a gradual path to a modern stack planned area by area. See our booking system modernization case study. For a process that moved from spreadsheets to a proper system, see the payroll management system case study and how to automate payroll.
Budgeting for a migration
Migrations are easy to underestimate because the old system hides so much. Budget separately for discovery, building, data migration, testing, training and the period after the switch. Keep a contingency for surprises found during discovery and data checks. A staged approach helps here too: each stage has its own estimate, and what you learn in early stages makes later estimates more accurate. See pricing and estimates.
Common mistakes
- Copying every old feature, including ones nobody uses.
- Leaving data migration until the end.
- Testing with made-up data instead of copies of real data.
- Switching over without a way back.
- Shutting down the old system too soon.
Checklist
- Old system documented, including hidden rules.
- Approach chosen: improve, staged, all at once or package.
- Scope trimmed to what is really needed.
- Data migration planned, rehearsed and checked.
- Outputs compared with the old system.
- Users trained and supported.
- Cutover and rollback plans written.
- Old system archived after a safe period.
For multi-customer systems, also read multi-tenant SaaS architecture explained.
A migration done this way is slower to start but far safer. Each step is small, tested and reversible, and the business keeps running throughout. By the end, you have a system your team understands and can change with confidence.