Taking over from another vendor

Takeovers start with a paid technical audit, one to two weeks depending on system size. We inventory what exists — code, infrastructure, accounts, credentials, documentation, contracts — and produce an honest map of risks and gaps. Sometimes the verdict is "this is better than you feared"; you deserve to know that too, before spending more.

• Domains, DNS, and certificates moved into accounts you own — this is priority one, since losing a domain is losing the business.
• Cloud accounts, repositories, and third-party services transferred or recreated under your ownership.
• Credentials rotated wholesale: every password, key, and token the previous vendor ever held.
• If the previous vendor is uncooperative, we work the providers’ recovery processes — we have done this more times than we would like.

The first engineering work is never a rewrite. We stabilize: monitoring on, backups verified, deploys reproducible, the riskiest single point of failure addressed. Only with the floor solid do we plan improvements — at which point you have real information and real options instead of pressure and guesswork.

• You do not own your own domain, cloud account, or source code — every week of delay deepens the hostage situation.
• A single person (theirs or yours) is the only one who can deploy or fix production.
• Backups exist but nobody has ever restored one, or backups live inside the same account as production.
• Invoices grow while delivery shrinks, and every question gets a change-order quote.
• The vendor resists giving you read access to your own systems "for security reasons."

None of these require drama to fix — most takeovers are cordial, and we are scrupulously professional with outgoing vendors. But each flag above gets harder to unwind the longer it stands, and two or more together is how businesses end up negotiating for their own property.