Changing vendors

Change vendors without stopping the roadmap.

The repositories transfer in an afternoon. The context does not. We take over systems built by someone else — and make sure leaving us is cheaper than leaving them was.

Talk to a tech lead
What actually breaks
R.1
Decision history
Why the queue was chosen over a cron job, which workaround is load-bearing. Without it a new team re-litigates settled decisions or breaks something it assumed was accidental.
R.2
Operational knowledge
What fails at month end, which alert is noise, what the manual step before the release does. It lives in people and expires with their contract.
R.3
Access
Registrar, DNS, CI secrets, the cloud account created on a personal address in year one. This is what turns a transition into a negotiation.
How we take over

A takeover is engineering work, not a contract end date.

S.1

Overlap, and ship during it

We start while the outgoing team is still engaged, and we ship small changes through their review. You learn more from a rejected pull request than from any handover document.

S.2

Inventory before notice

A complete list of accounts, providers and credentials, with owners named — collected while there is still commercial leverage, not after.

S.3

Reconstruct the decisions

Architecture as built rather than as designed, recorded walkthroughs per subsystem, and an honest debt list. We write down what the last team knew.

S.4

Production inside the first month

A takeover has worked when the new team has merged production code, can deploy without the outgoing vendor in the room, and can explain a decision it did not make.

Your repos, your cloud

From day one, in your accounts. You are switching because leaving was hard last time; signing a replacement without fixing that means doing this again in three years.

Interview the tech lead

The person in that conversation is the person in your repositories. Nobody is swapped for a cheaper profile once the work starts.

Handover as definition of done

Documentation, ADRs and handover drills are part of shipping, not a closing favour. Leaving must always be cheap.

FAQ

Taking over someone else’s codebase.

Will you work on a codebase you did not write?

Yes — most takeovers start that way. We begin with characterisation tests and a read of what production actually does, rather than a rewrite proposal.

What if the previous vendor will not co-operate?

It happens. Then the transition runs on artefacts instead of goodwill: production behaviour, the access inventory you can assemble yourself, and tests written around current behaviour before anything changes.

Do you recommend rewriting?

Rarely, and not first. A rewrite trades a system you understand badly for one that does not exist yet. Strangling the parts that hurt is usually cheaper and always reversible.

How long before you are productive?

Production code inside the first month is the bar we hold ourselves to. If the system makes that unrealistic, we say so before you sign rather than after.

Contact us

Bring us a system you can't afford to get wrong.

[email protected]
A technical call, not a sales call: an hour with a Hazesoft tech lead on your architecture and constraints. If we're not the right shape of help, we'll say so.