Dependency

How do I move a software project from one agency to another?

A transition in eight steps, from before notice is given to the consultation window afterwards — with the two places where it usually goes wrong marked.

Short answer

Secure ownership of every account before you give notice, derive an independent technical picture while everybody is still cooperative, and plan a real overlap in which the incoming team deploys, restores a backup and gets written answers to specific questions. The two expensive mistakes are giving notice before auditing ownership, and leaving a gap between the two agencies in which nobody is responsible.

#Before notice

Everything here is cheaper and easier while the relationship is still normal. That is not a tactic; it is arithmetic.

  1. Audit ownership of every account

    Domain, DNS, cloud, database, backups, repository, CI, payment provider, email, monitoring, app stores. For each: whose identity is it in, who is billed, and where do the recovery contacts point?

    Most of this you can establish yourself by looking, without asking anybody anything.

  2. Transfer anything critical that is not yours

    Domain and cloud organisation first. These have multi-day processes and at least one of them will need the outgoing agency's cooperation — which you have far more of today than you will next month.

  3. Take an independent copy of the data

    A backup you hold and can open yourself, in a place the supplier does not control. This is the one insurance policy that covers the worst case.

  4. Derive the technical picture

    Now, while cooperation is easy. Its gaps become the agenda for the whole transition, and having it before the conversation changes the conversation.

  5. Read the termination clause

    Notice period, deliverables on termination, intellectual property, what happens to accounts. Ten minutes, and it changes how you plan everything above.

#Giving notice

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 to agree, in writing, at this point:

  • The overlap. How long, who is available, and what it is for.
  • The question list. You will send up to twenty-five specific written questions; they answer them in writing by a stated date.
  • The demonstration. The incoming team runs, deploys, rolls back and restores — themselves, with the outgoing team advising.
  • The acceptance criteria. Ship, recover, explain — rather than "documentation delivered".
  • The consultation window. A small number of paid hours over the following month or two.
  • The account transfers that remain outstanding, with dates.

A note on tone

Most agency changes are not acrimonious. A supplier who is being replaced for reasons of cost, capacity or focus usually wants a clean exit and a reference. Assume that until shown otherwise — a transition conducted as if it were a dispute tends to become one.

#The overlap

Two to six weeks, depending on the size of the system. This is the part that is worth paying for twice.

The overlap exists to convert assumptions into facts, and it should be spent on doing rather than on presenting. In rough order:

  1. Week one: the incoming team gets it running locally, from the written instructions alone, and corrects those instructions as they go.
  2. Week one or two: they deploy a trivial real change to production, roll it back, and restore a backup into a scratch environment. All four themselves.
  3. Throughout: the written question list is answered, in writing, by the outgoing team.
  4. Last week: the incoming team ships something real and useful, unaided, and takes the acceptance test.

What the overlap is not for: a series of knowledge transfer presentations. Watching somebody deploy transfers nothing, and a recorded walkthrough is watched once by people who are not the ones who will need it.

#Setting up the incoming agency

Two decisions here determine whether you have reduced a dependency or moved it.

  • Accounts stay in your name. Give access, not ownership. Every new account created during the engagement is created in a company identity. Write it into the contract — it is a standard clause and rarely contested.
  • The understanding lands somewhere you keep. The first two months of any new engagement are spent learning the system, and you are paying for that whether or not the result is durable. Ask that the technical picture be produced and maintained in something the company owns, as a deliverable of the onboarding phase.

The second point is cheap for the incoming agency — they are doing the work anyway — and it is the difference between this being the last expensive transition and the first of several.

#After the switch

  • Rotate everything the outgoing team could have seen, after ownership is confirmed and your own routes verified. Hygiene, not accusation.
  • Remove personal access — accounts, keys, tokens, and anything on individual machines.
  • Analyse the system again and compare it with the picture from before the transition. This is the most direct account there is of what actually happened during it.
  • Keep the consultation window open and actually use it. The questions that matter surface once the new team starts changing things, usually in week five.

#What it costs

Be honest with yourself about this before starting, because underestimating it is how a transition turns into a crisis.

The cost lines of an agency change
LineTypical shape
OverlapBoth agencies billing for two to six weeks
Reduced outputThe incoming team is slower for one to three months, and you are paying full rate
Your own timeSubstantial, and usually not budgeted at all
Consultation windowA small retainer for one to two months
ReworkSome. A new team will change things they do not understand yet

The delay calculator lets you put your own figures against the second line, which is the one that dominates and the one people leave out.

#What goes wrong

Giving notice before auditing ownership.

Instead Audit first, transfer what is critical, then talk. This is the single most expensive mistake available in an agency change.

A zero-day gap between the two agencies.

Instead Overlap them and pay for it. The gap is where every assumption turns out to be wrong, with nobody responsible for any of it.

Letting the incoming agency create the next set of accounts.

Instead You create them; they are invited. Otherwise you have paid to move a dependency rather than to reduce one.

Accepting “we will document everything” as the exit deliverable.

Instead Twenty-five written questions and three acceptance tests. Both are checkable; “documentation” is not.

Treating the final invoice as the end.

Instead Keep a paid consultation window. The expensive questions arrive after the new team starts changing things.

#What this does not cover

What this does not do

  • Choosing the incoming agency. Different problem, and mostly not a technical one.
  • Contract terms, notice periods, intellectual property and dispute resolution. Ask somebody qualified.
  • What to do when the outgoing supplier stops cooperating entirely. Then: independent data copy, derived picture, and every account moved — in that order, quickly.
  • Anything specific to a regulated industry, where a change of processor carries obligations of its own.

Establish what you have, before either side is motivated.

A technical picture derived from the code rather than written by the party you are leaving — and the incoming team can be the one who runs the analysis.

Build your project map — free Check readiness first