Taking over software from another vendor: what to check first
Before a new team changes anything, find out who controls the system, what access exists, how it is released, and whether it really needs a rebuild.
Rosaan Ramasamy · · 3 min read
Improve or replace your current software?
A checklist for deciding whether to repair a system, replace one part or plan a full rebuild, without committing before the evidence is in.
In short
Inspect the current system and the business problems it causes before choosing a rebuild. Improve it when the main workflow is sound and the problems are bounded. Replace a component when one part is holding the rest back. Rebuild only when the core system cannot meet the agreed needs at an acceptable cost and risk.
An old system can be frustrating without being beyond repair. A new system can also inherit the same unclear rules and data problems. The decision needs a short, honest assessment of what fails today and what must keep working during any change.
Check the current system
Start with the users and the operating risk:
- Which tasks fail, take too long or require workarounds? How often does that happen?
- Which reports or records does the business rely on for daily decisions?
- Which parts still work well and would be costly to replace?
- Who controls the source code, hosting, database, backups and vendor accounts?
- Can changes be tested and released safely? Is there a way back if a release fails?
- Which integrations and data formats would a replacement have to preserve?
Use real examples rather than general verdicts such as “the whole system is slow”. The vendor handover guide covers access and release checks in more detail.
Compare the options
| Option | Consider it when | Main question to resolve |
|---|---|---|
| Improve | The main workflow and the way data is stored still fit, and the problems sit in specific places. | Can the change be tested without disrupting the rest of the system? |
| Replace a part | A specific module or integration causes most of the trouble. | How will the old and new parts exchange records during the transition? |
| Rebuild | The system’s core design blocks essential work, and no reasonable repair will fix it. | How will data, users and daily operations move over safely? |
Replacing one part at a time still needs the old and new parts to share data cleanly. A rebuild still needs a plan for the current system while the new one is being built.
A common case: slow reporting
A company has a booking system staff know well, but its weekly reporting takes a day of manual exports. If the booking records are reliable, fixing the report, or producing it automatically, solves the problem. Replacing the booking system first would add migration and training work without addressing the immediate cause. If the booking rules themselves cannot represent current operations, the decision changes.
That is why the investigation comes first: name the failure, test the likely cause, then decide.
Decide the next step
Write down the problem, affected users, evidence, options, transition risk and the person who can approve a decision. If the cause is still unclear, a System Review investigates it and tells you what to fix first. Once the direction is clear, the work becomes System Improvement or a scoped Custom Project.
Founder and Managing Director, Antdragon
Rosaan started Antdragon in 2020 to be the team that stays accountable once software goes live, and works with business owners on the systems they rely on every day.
Filed under Existing systems and takeover
Keep reading
Why software requirements keep changing after the scope is agreed
Most businesses only fully understand what they need once people start using the software. Why that happens, and how the way you pay for development makes it easier or harder to handle.
Rosaan Ramasamy · · 5 min read
How to plan an integration between business systems
A worksheet for the records, owners, access, errors, reconciliation and real-world tests behind a business system integration.
Rosaan Ramasamy · · 2 min read