Short answer
#Before you give notice
The order of these matters more than the speed of any of them.
-
Establish ownership of every account
Domain, DNS, cloud, database, backups, repository, CI, payment provider, email, monitoring, app stores. For each: is the owning identity yours, or theirs?
This is a survey, not a confrontation. Most of it can be done by looking.
-
Transfer anything critical that is not yours
Domain and cloud organisation first. Several of these have multi-day processes and at least one will need the outgoing agency's cooperation — which you have far more of today than you will after notice.
-
Fix recovery addresses
A company account whose recovery email is somebody at the agency is not a company account. Check every one you cannot afford to lose.
-
Get an independent technical picture
Derived from the code, with citations, and an explicit list of what could not be established. Done now, while everybody is still cooperative, its gaps become the agenda for the transition.
-
Read the contract for the exit terms
Notice period, what is deliverable on termination, who owns the intellectual property, what happens to accounts. Find out now, not during the negotiation.
-
Then talk to them
With ownership secured and a picture in hand, the conversation is about scheduling a professional transition. Without them, it is a negotiation in which the other side holds the assets.
#What an outgoing agency owes you
Write these into the exit as deliverables. Most reputable agencies will agree to all of it; the ones that will not have told you something useful.
Assets and access
- Every account transferred to company-owned identities, verified by you signing in
- Complete repository history, not a squashed snapshot
- Every credential and secret, delivered securely and then rotated by you
- A list of everything that runs and is not in the repository Scheduled tasks, console-created resources, scripts on machines. This list is where the surprises live.
Operability, demonstrated rather than described
- A working local environment set up by the incoming team, not watched
- A production deployment performed by the incoming team while the outgoing one is available
- A backup restored into a scratch environment
- The monitoring and alerting inventory: what alerts, to whom, and what it means
Knowledge that only they have
- Written answers to a specific question list — not “documentation” A list of questions gets answered. An open-ended request produces a hurried document about what somebody remembers.
- Which parts they would be nervous about somebody changing, and why
- What breaks regularly and what they do about it
- Which outside parties depend on this system — partners, integrators, API consumers
- Any manual step, and how often it has to happen
#What an incoming agency needs
And what you should be careful not to give them by default.
A new agency will want repository access, cloud access and time. All reasonable. Two things are worth deciding deliberately rather than by default:
- Accounts stay in your name. Give access, not ownership. The most common way one dependency becomes another is that the new supplier creates the next set of accounts on their own organisation because it was quicker.
- The understanding they build should land somewhere you keep. The first two months of any new engagement are spent learning the system. If the result of that lives only in their heads, you have paid to move your dependency rather than to reduce it.
A reasonable way to put the second one: ask that the technical picture be produced and maintained in something the company owns, and treat it as a deliverable of the onboarding phase. It is cheap for them — they are doing the work anyway — and it is the difference between this transition being the last expensive one and being the first of several.
#The gap where nobody is responsible
The characteristic failure of an agency change is not a dramatic one. It is a three-week period during which the old team has stopped caring and the new team has not yet started being able, and something needs doing.
Ending the old contract on Friday and starting the new one on Monday.
Instead Overlap them, and pay for it. The overlap is where every “it should work” is converted into a fact, with somebody available to explain why it did not.
Letting the outgoing team perform the transfer steps while the incoming team watches.
Instead Have the incoming team do every step, with the outgoing team available. Watching a deployment transfers nothing.
Rotating credentials before ownership is confirmed.
Instead Confirm ownership, create your own routes in, verify them, then rotate. The reverse order can lock you out of an account that was only ever in their name.
Treating the final invoice as the end of the transition.
Instead Keep a defined, paid consultation window for a month or two afterwards. The questions that matter surface once the new team starts changing things.
#Measuring whether it worked
Same three tests as any handover, and they are worth writing into the exit terms as acceptance criteria in place of "documentation delivered":
- The incoming team deploys a real change without contacting the outgoing one.
- They restore a backup into a scratch environment.
- They answer ten questions about the system — chosen by you — correctly, in writing.
There is a fourth measurement worth having, and it is the one that tells you what actually happened during the engagement you are ending: analyse the system at the start of the transition and again at the end, and compare them.
#Where 1ADK helps, and where it does not
Where it helps
- A picture that belongs to you rather than to either agency.
- Gaps as a specific question list to put in the exit terms.
- A before-and-after comparison of the transition.
- Something for the incoming team to be checked against.
- Continuity: the next change of supplier starts from a record, not from nothing.
Where it does not
- Transferring domains and cloud accounts.
- Contract terms, notice periods and intellectual property.
- Judging either agency's work.
- Proving the system runs — only running it does that.
- Negotiating with a supplier who has decided to be unhelpful.
Questions people actually ask
Secure ownership first where you can do so without an announcement — several transfers are ordinary administration that does not require explaining. What you should not do is give notice and then discover that the domain is in their name, because at that point a routine transfer becomes leverage in a commercial conversation.
Long enough for the incoming team to deploy a real change, restore a backup, and get written answers to their questions. In practice two to six weeks depending on the size of the system. A zero-day gap between two agencies is the single most expensive way to save money on a transition.
Everything that is a property of the system: structure, dependencies, interfaces, data flows, what runs on a schedule. What is not recoverable is why decisions were made and what they know operationally. Get the picture derived from the code, get every account moved, and treat their cooperation as a bonus.
They will, and it is a large part of what you are paying for in the first months. The question worth asking is whether the result of that reading ends up somewhere the company keeps, or inside the new agency — in which case you have moved the dependency rather than reduced it.