Your vendor is gone and the system has to keep running: the first 30 days

The day the vendor disappears, the system doesn’t stop. Staff still sign in every morning, customers still pay through it, and someone will ask you: if it breaks, who fixes it?

This is the order of work we follow when we take over a system someone else built. It is written so that someone who isn’t a developer can follow it. The order matters: the first week makes the rest possible.

1 Week 1: keys and a backup Every account in your organisation's name, and one backup restored.
2 Week 2: the map One page: the parts, the data, the costs, what renews when.
3 Week 3: the risks Security, PDPA, and whether tests and deploy steps exist.
4 Week 4: the decision Sort the system into three piles before anyone rewrites anything.

Fig. 1 Each week stands on the one before it. Without the keys you can't draw the map, and without the map you can't judge the risks.

Week 1: get the keys back

Everything starts with one question: who holds the keys? List every account the system depends on, and whose name each one is in.

The domain and DNS. If the domain expires, everything stops at once. Note the renewal date.
The cloud or hosting account the system runs on, and the card that pays for it.
The source code repository, such as GitHub or GitLab.
App Store and Google Play developer accounts, if there is a mobile app.
LINE Official Account and LINE Developers, if anything runs on LINE.
Every service the system calls: email sending, payments, SMS.

For accounts already in your organisation’s name, change the passwords, turn on two-factor sign-in and make sure two people on your side are owners. For accounts in the vendor’s name, or a vendor employee’s, ask in writing for them to be transferred. Most can move without rebuilding anything: repositories, App Store apps and Google Play apps can all be transferred to another account.

1 In the vendor's name Accounts held by the vendor, or by someone who worked there.
2 Ask in writing A written request to transfer each one to your organisation.
3 In your name New passwords, two-factor sign-in, and two owners on your side.

Fig. 2 Most accounts can be moved without rebuilding anything: repositories, App Store apps and Google Play apps all transfer to another account.

One more job this week: take a backup now. Don’t assume a backup exists until you have seen the file and restored it, once, somewhere separate.

Week 2: draw the map

You can get in. Now find out what is where, and write it on one page:

the parts of the system, where each runs, and how they talk to each other
where the data lives, especially personal data
every monthly cost, who pays it, and what renews when: domains, SSL certificates, the Apple developer membership
anything that runs on a schedule in the background, such as a nightly batch

That page becomes the most valuable document your organisation has about this system, and it is the first thing the next vendor will ask for.

Week 3: look at the risks

With the map in hand, check three things.

Security. Do the libraries the system uses have known vulnerabilities? When were the servers last updated? Who can still sign in? If the old vendor kept access “just in case”, remove it.

PDPA. Under Thai law your organisation is the data controller, and a vendor that still holds the data is a data processor, which needs an agreement between you. If there is no agreement and you no longer work together, ask them to delete the data and confirm it in writing.

Knowledge. Are there automated tests? Is there a written way to deploy? If neither exists, every change will be slower and riskier than it should be. Know that before you promise your users a new feature.

Week 4: decide, but don’t start by tearing it down

Many new vendors will propose a rewrite. Sometimes it is truly needed; usually it isn’t. A system people use every day holds more knowledge about your business rules than any document. Rewriting it throws that knowledge away and relearns it on your budget.

The safer way is to sort the system into three piles:

What works. Leave it alone; add tests and monitoring.
What needs fixing. Fix it one piece at a time, with tests guarding each change.
What is beyond fixing. Rebuild it, and only it.

What works Leave it alone; add tests and monitoring.
What needs fixing One piece at a time, with tests guarding each change.
Beyond fixing Rebuild it, and only it.

Fig. 3 A rewrite throws away every part that works. Sorting first keeps the work to the part that is beyond fixing.

That decision should come from reading the code and a written list of risks, not from anyone’s instinct.

Three traps we see often

Letting the old vendor keep access “for emergencies”. Access nobody watches is a hole. If it is truly needed, create a temporary account that expires.
A backup nobody has restored. Until it has been restored successfully, you can’t rely on it.
Promising new features before the system is steady. Every feature added to a system nobody understands yet makes the old problems harder to find.

Want to know how exposed your system is? Try the 12-question vendor risk check. It takes about three minutes.