The freelancer has moved on, the agency contract is ending, or the one developer who knew the system has left. Customers are still using it. We review what you have, stabilise it and look after it from there.
The costliest takeover mistake happens before any new team arrives. Someone cancels a hosting plan, a domain lapses, or a former supplier's account is shut, and a part of the live system that depended on it stops without warning. Running software often relies on services and credentials you can't see from the main code repository.
The signs that a takeover is due are usually familiar. Nobody is confident enough to release a change. Small bugs collect because fixing one breaks another. A renewal email arrives for a service nobody recognises, and the person who would know has stopped replying.
So the first job is to understand what you have. Keep everything running as it is while we build an inventory and go through it with you.
Change credentials and close accounts after the handover, not before.
Confirm who can grant access to each item, and whether it belongs to you or to a previous supplier.
We work through the list above with you, and with the outgoing team if they're available, recording what exists and who controls it.
We check how the application is built, deployed and supported, where it is fragile, and which documentation is missing or wrong.
Urgent issues come first: expiring certificates, missing backups, security gaps, anything that could take the service down. These are kept apart from longer-term changes.
Once access has moved and the risks are known, we agree who handles hosting, support and new development, then carry on with software maintenance and improvements.
If the application does its job and can be maintained, keeping the technology stack is often the better decision. A rewrite pauses product work and brings risks of its own.
Unsupported frameworks, security problems or a design that blocks the roadmap can justify bigger change. We'd plan it as application modernization, step by step, with the live system kept running.
A takeover ends in the same place as a new build: a platform someone looks after week to week. We already do that for the client platforms we designed and built, such as DataStandard and Easy Inventory, covering hosting, maintenance, support and continued development. Taking over someone else's code adds the review at the start, because we didn't write it and won't assume we understand it.
Your code, data and accounts stay yours throughout. If you later want to move the work in-house or to another team, we plan that handover as carefully as this one; our page on ownership and handover sets out how.
Yes, and most takeovers do. The review establishes what can be recovered from the code and the running system, and what needs rebuilding or writing up.
It depends on the size of the system and how quickly access can be arranged. We agree the scope of the review with you before starting, and share findings as they come rather than waiting for one final report.
That helps a great deal when it's possible. A few working sessions where they walk through deployment and known problems can save weeks of investigation, and we'll prepare the questions in advance.
It's harder, but often workable if you control the main accounts. That's why confirming ownership of the hosting, domain and repository comes before anything else.
Send us what you know about the system today and we'll help you build the access list first.