Improve the system you already depend on.
Older software can be slow to change and still hold years of business rules. We review what you have, decide what to change first, and move to the updated system in stages your operation can absorb.
The order system was written years ago by a developer who has since moved on. It works, mostly. Reports take a minute to load, nobody dares touch the pricing code, a few staff export to Excel every evening to do what the system can't, and the server it runs on is past its support date.
Throwing it away is tempting and usually risky. The old application holds rules nobody wrote down: the customer who always gets extended credit, the tax treatment for one product line, the field that means something different on older orders. Replacing it is an operations decision as much as an engineering one.
So we begin by reading the code and the data, and by watching how people actually use the system. The choice of approach comes after that.
Three ways forward.
Fix in place
Update hosting, dependencies and the worst-performing parts while keeping the application. Suits software whose design is sound but neglected.
Replace one part at a time
Rebuild a single component, such as reporting or customer sign-in, beside the old system, with both running until the switch.
Rebuild
A new application with the data migrated across. Right when the old design blocks what the business needs next, and only after its hidden rules are written down.
How a staged modernization runs.
Map what exists
Code, database, integrations, hosting, and the people and processes that rely on each part. We also collect the undocumented rules from the staff who know them.
Pick a first change
Usually the part causing the most pain with the fewest dependencies, such as a slow reporting module that can be replaced without touching order processing.
Move and check the data
We clean and transfer the records, then compare old and new outputs until the figures agree.
Change over with a way back
The cut-over time and any interruption are agreed with you in advance, and the old path stays available until the new one has proved itself.
Take the next part
Every release reveals more about the system, so each following step is planned with better information.
Risks we plan around.
Data that doesn't add up
Years of records collect duplicates, blank fields and values typed differently by different people. We profile the data early so the clean-up is scoped, not discovered at cut-over.
Connections nobody listed
A nightly file sent to a supplier, a report a bank pulls each month. We trace outgoing traffic and scheduled jobs so nothing stops silently.
Habits built around old quirks
Staff often work around a bug so long it becomes the process. We ask them to walk us through their day before deciding what the new version should do.
Keeping the lights on meanwhile
The business keeps trading during the work, so the old system still needs fixes. We agree who handles those and how they flow into the new build.
The awkward details we will ask for.
- Old exports and reports your team still relies on
- Rules that live in someone's head rather than in the code
- Every system the application talks to, and how
- Who holds admin access to the servers, domain and database
- Known bugs and workarounds staff use every week
- Busy periods when no changeover should happen
Useful before you decide.
Preparing for data migration
What to clean, check and decide before records move into a new system.
Read the guide ServiceSoftware maintenance
Once the system is updated, how we keep it that way.
See maintenance BlogBuild, buy or integrate?
Sometimes the answer to an ageing system is a ready-made product plus an integration.
Read the postTell us about the system everyone works around.
Send a short description of what it does and what hurts, and we will suggest where a review should start.