Businesses change software companies for many reasons. Deadlines are missed. The old supplier closes. Replies are slow. Or the business simply grows past a small team. Whatever the reason, the handover is a risky moment. Done badly, it can lock you out of your own systems.
Here is what a safe handover looks like.
Before you switch: make sure you own everything
Before you end the old contract, check that your company owns, and can log in to:
- The code, with its full history
- Hosting accounts, servers and databases
- Your domain name and its settings
- Services such as payments, maps, email and analytics
- App Store and Google Play accounts
- Settings files and any documentation
These should be in your company's name, not the old supplier's. If they are not, moving them is the first job.
Week 1: Understand what you have
The new team's first job is a review, not new features. They should answer simple questions:
- Can the system be built and put live from the code as it is?
- Are the tools it uses still supported and safe?
- Where is personal data kept, and is it protected?
- Are there tests and backups, and do they work?
- What errors and slow pages are users seeing?
You should get a short written report in plain English: what works, what is at risk and what it would cost to fix.
Week 2: Make changes safe
Before anything new is added, make changing the system safe:
- A test copy of the system (often called "staging") to try changes first
- Automatic releases, so every update goes live the same way
- Backups that have been tested by actually restoring them
- Alerts when something breaks
This work is not exciting, but it stops a small fix from turning into a big outage.
Weeks 3 and 4: Fix what hurts most
Now fix the problems that cost the business most: the bug customers keep reporting, the slow page people leave, the security update that keeps being delayed. Quick, visible wins rebuild trust in the product and in the new team.
Day 30: Agree the plan
By the end of the first month you should have a clear picture and a plan: what to make more stable, what to improve, and whether any part really needs rebuilding. The plan is based on facts, not frustration.
What a good new team does
A good new team does not blame the last one or push for a rebuild on day one. They secure your access, write down what they find, and make the system safer before making it bigger.
Our bespoke software team often takes over existing systems, and always starts with this review. If you are thinking about a switch, let's talk.
Questions
Frequently asked questions
What do I need from my old developer before I switch?
Full access to the code, hosting, domain, databases, app store accounts and any other services, plus documentation and settings. Make sure all of these are in your company’s name.
Can a new team work with code they did not write?
Yes. A review in the first week shows how the system is built, where the risks are and what can be changed safely.
Should we rebuild the application after the switch?
Not straight away. Most systems can be made stable and improved. Only think about a rebuild if the review shows the system cannot support what you need.