Agency Switch: Handover Protocol for Client Sites

Where a handover goes wrong

The separation itself is rarely the problem. The problem is the gap between the outgoing agency's last working day and the new one's first. Contracts keep running inside that gap, certificates expire, reminders reach a recipient who is no longer responsible, and nobody feels accountable for the domain. What ends up in dispute is almost never the design; it is control over access: who can move the domain, who can renew the certificate, who can reach the database. A record that pins each of those positions to a date, a recipient and a confirmation costs half a day and ends the argument before it starts.

The most common trigger is a registration made years ago out of convenience: the agency put the domain in its own name because that was faster than arranging a power of attorney. As long as the relationship holds, nobody notices. At separation the question of who owns the name is suddenly on the table. The same question arises for certificates, for accounts with mail providers, and for every tool the agency runs for the client inside its own account. Anyone who wants to see how tight the deadlines are will find the numbers in the article on domain expiry and renewal windows.

• Domain and AuthInfo - registrant according to the registry, responsible provider, auth code, planned transfer date.
• DNS zone file - every record in plain text, including the time to live, mail routes and the verification records used for sending.
• Hosting and database - server name, access to file storage, database dump with a date, the time of the last backup.
• Source code and build path - where the source lives, access to it, build instructions, dependencies, a way to deploy by hand.
• Certificates and private keys - issuer, expiry date, renewal path, where the private key is stored.
• Accounts with providers - mail delivery, payment provider, map service, search console: for each account the registered holder and the way to change it.
• Measurement data and reports - audience data, availability series, screenshots, report archive, each with an output format.
• Proof of deletion - what the outgoing provider deletes after the handover, when, and who confirms it.

Each of these eight positions has three possible states: handed over, deliberately retained by the outgoing provider, or not present at all. The third state matters most, because it stops the successor from spending weeks looking for something that never existed. Anyone who separates access per client anyway has most of this list ready in the system; what such a separation with an audit trail looks like is described in the article on access rights, roles and the team audit log.

The domain and the auth code

Moving a .de domain runs through the AuthInfo, a password created by the losing provider and stored at the registry. The rules for it are strict: the auth code must be between 8 and 16 characters long, and the characters I, l, O, o, 0 and 1 are not permitted because they are too easily confused in print (DENIC). That sounds like a footnote, but it is the most common reason a first attempt fails: the code is read out over the phone, a one turns into a lowercase L, and the request errors out in a way each side blames on the other. The auth code therefore belongs in the record as a file, not as a spoken message.

Two further properties decide the schedule. First, the registry stores only an encrypted version of the auth code, not the plain-text password (DENIC), so a lost code cannot be looked up, only reissued. Second, the code expires automatically after 30 days and has to be requested again (DENIC). Request the auth code in November for a transfer planned in January and you start over. If the code matches the stored value, on the other hand, the domain moves immediately (DENIC); there is no waiting period between the new agency's request and the change of responsibility in which anything could still be clarified.

TRANSIT and the window after deletion

If the previous provider terminates the contract without a successor in place, the domain does not simply vanish. The TRANSIT procedure is a free service for all domain holders and protects against the unintended loss of a domain; the domain is not deleted straight away but temporarily administered by the registry itself and cannot be registered by anyone else (DENIC). That is the safety layer that saves a badly planned separation from a total loss - but it is time limited, and it assumes the holder can be reached.

1. One month to decide. The domain holder has one month to decide on a provider change (DENIC). The individual date is in the letter from the registry, not in a general rule.
2. Reachability decides. If the letter cannot be delivered, the registry terminates the domain contract by email and the domain is deleted (DENIC). An outdated postal address is therefore not a cosmetic flaw but the road to deletion.
3. 30 days after deletion. Once deleted, a domain can be registered again by the previous holder only within 30 days - the Redemption Grace Period - and after that window it is available for registration by anyone (DENIC).

That third deadline is the most expensive one in the whole sequence because it runs silently. Nobody gets a reminder, and the loss only shows up when the address leads nowhere or mail stops arriving. A handover record therefore holds more than access data: it holds three dates - the day of the transfer, the day the old contract ends, and the day responsibility for renewal passes to the new agency. Monitoring those dates instead of noting them down reveals a gap before it becomes a deadline, and that includes monitoring domain and DNS records in day-to-day operation.

The auth code is not a bargaining chip

In practice the auth code is routinely treated as collateral: settle the invoice, then get the code. German law does not support that. Anyone registering a domain on behalf of a client generally acts as a trustee, and for an agent the rule is that the agent is obliged to hand over to the principal everything received in order to carry out the mandate and everything obtained from conducting the business (section 667 of the German Civil Code). A domain and the access to it are exactly that - something obtained from conducting the business. The claim does not depend on whose name is in the register.

A specialist article on the claim for release summarises the case law of the Federal Court of Justice as follows: as early as 2010 the court held that an agency acting as trustee has no right of retention over the domain or the auth code, that it may not refuse release even if it had itself entered as the domain holder, and that outstanding claims do not create a right of retention either (Hoesmann law firm). For the outgoing agency that means holding the code back does not improve the prospect of payment; it moves the dispute from the invoice to the agency's own conduct - and produces exactly the reference that gets read out at the next pitch.

Access inventory: what is actually handed over

A handover record is not a document full of good intentions but a table with rows that get ticked off. Each row names the position, the place it hangs on, and what the successor actually receives. The decisive difference from a list read out in a closing meeting: the table forces a decision on whether a position exists at all. "The host takes care of that" turns into a name, and "it renews automatically" turns into a renewal path with an owner.

The last row is the one most often missing, and it is the only one that protects the outgoing provider. Without proof of deletion it stays open whether the client's data still sits on a secondary machine two years later; with it, the question is answered before it is asked. How long a given measurement series should be kept at all is a topic of its own and is covered in the article on retention periods for monitoring and analytics data.

Data, deletion deadlines and the proof

Once the agency has processed personal data for the client - visitor data, form content, screenshots from areas behind a login, contact details of alert recipients - the handover does not end with an account but with a decision. After the end of the provision of processing services, the processor has to delete or return all personal data at the choice of the controller and delete existing copies unless Union or Member State law requires storage (Article 28(3)(g) GDPR). The choice belongs to the client, not to the agency - and it belongs in the record in writing, with a date.

What the contract has to contain in detail is set out elsewhere: the article on the data processing agreement under Article 28 walks through the eight points of the provision. For a handover the second to last one matters most: it describes exactly the day the cooperation ends, and it is the only part of the agreement that is needed only then.

The record as a document

A usable record fits on a few pages and carries the same fields for every position: label, state, recipient, date, evidence. The evidence is not a word but a result - a registry lookup, a response header, an expiry date read off the certificate, a file listing of the export. Keep the record machine readable and it can be checked against reality on the cut-off date instead of being believed.

{
  "client": "Example Ltd",
  "cutoff": "2026-12-31",
  "outgoing": "Agency A",
  "incoming": "Agency B",
  "positions": [
    {
      "position": "domain",
      "label": "client.example",
      "state": "handed_over",
      "recipient": "Agency B",
      "date": "2026-12-08",
      "evidence": "registry lookup 2026-12-09, provider changed"
    },
    {
      "position": "certificate",
      "label": "client.example, wildcard",
      "state": "handed_over",
      "recipient": "Agency B",
      "date": "2026-12-08",
      "evidence": "notAfter=2027-03-14, renewal from 2027-02-12 by Agency B"
    },
    {
      "position": "measurement_data",
      "label": "availability and audience 2024-2026",
      "state": "returned",
      "recipient": "Example Ltd",
      "date": "2026-12-15",
      "evidence": "export csv and json, 41 files, checksums attached"
    },
    {
      "position": "deletion",
      "label": "client data in the systems of Agency A",
      "state": "scheduled",
      "recipient": "Example Ltd",
      "date": "2027-01-15",
      "evidence": "confirmation after backups roll over, accounting records excluded"
    }
  ],
  "open": []
}

The field for open items is deliberately the last one and deliberately empty. As long as something is listed there the handover is not finished, and both sides look at the same list. A record that hides open items reads like completeness on the cut-off date and turns into an invoice six weeks later. The lesson from acceptance testing applies here as well: what was not measured was not handed over - the same logic is described in the article on website acceptance with a test report.

A handover record does not protect the party that demands it. It protects the party that writes it. Whoever can show what was handed over and what was deleted argues about invoices instead of accusations.

— XICTRAQ

Rights in design and source code

Access is one half, rights are the other. Whether the successor agency may develop the existing design further is not decided by possession of the files but by the scope of the rights of use that were granted. Where the types of use are not expressly and individually specified when a right of use is granted, the scope is determined by the purpose of the contract as jointly assumed by both parties (section 31(5) of the German Copyright Act). In case of doubt, what was not expressly transferred stays with the author - a rule that hurts for the first time at separation.

• Name the right to modify explicitly. A right to use a design is not automatically a right to change it. Without that point the successor may operate the site but not rebuild it.
• Separate third-party components. Fonts, images and purchased building blocks carry their own terms. The record needs to state per component whether the licence runs in the client's name or in the agency's.
• Name what was custom built. A component built for the client is not the same as the agency's general library. Both may move along - but only once the conditions are settled.
• Access is not a right. Handing over the source does not automatically grant the right to develop it further; and granting the right does not mean a readable build path has been handed over.

Measure instead of promise

The difference between a record and an assertion is the counter-check on the cut-off date. It takes a few minutes and regularly turns up what got lost in the handover: a name record still pointing at the old server, a certificate whose renewal hangs on an account of the old agency, mail delivery running through a service nobody mentioned. The measurement is taken from the outside, with the same means the successor has available.

Four lines, four answers: where does the name point, which address responds, is delivery still standing, when does the certificate expire. The same questions come up every day afterwards, only without anyone asking them - which is why the cut-off date needs more than a measurement: it needs the handover of the monitoring itself. For reachability that is continuous uptime measurement, for registrant data a regular lookup of registry records.

International domains: the Transfer Policy

For domains under .com, .net or .org the German registry procedure does not apply; the ICANN Transfer Policy does. It sets a ceiling that helps during a separation: if the registrar does not provide facilities for the holder to generate their own auth code and to remove the ClientTransferProhibited status, it must provide both within five calendar days of the holder's initial request (ICANN). Five calendar days is therefore the span to plan with - and it starts with the request, not with the termination of the contract.

Two further points of the same rule belong in any argument about an unpaid invoice. First, the registrar of record must not refuse to remove the transfer lock or to release the auth code solely because there is a payment dispute with the holder (ICANN). Second, registrar-generated auth codes have to be unique per domain (ICANN) - a shared code for the whole customer account is neither permissible nor worth anything as evidence. Anyone taking over a domain with a transfer lock in place will find the background on lock states in the article on registry lock and EPP status codes.

A clean separation as a sales argument

A handover is the last act of one engagement and the first of the next. The client who is leaving will be asked how the separation went - by their successor in the role, by the new agency, by an acquaintance with the same question. A record that names every position and supplies every piece of evidence is worth more at that moment than any reference list, because it is the only thing the other side can verify. Conversely, a withheld account costs more than the invoice it was meant to secure.

For the incoming side the same applies in reverse: ask for the eight positions on day one instead of hunting for them in month three and you take over an inventory rather than a puzzle. And whoever wants to keep the client long term shows the handover as part of the offer - with a tenant in which access, expiry dates and reports are separated from the start. How that turns into a recurring offer is described in the article on monitoring under your own brand for agencies; regular reporting to the client is covered in the article on automated weekly reports.

A plan for the last thirty days

The order matters more than completeness. Start the domain transfer before the zone has been copied and you lose the chance to read it out again. Delete the data before the export has been checked and there is nothing left in hand. The following plan keeps the order and leaves room for a second attempt on every position.

1. Day 30 to 25: take inventory. Registry lookup, export the zone, list the accounts, record certificates with expiry dates, name the tools in use. The result is the table, still without states.
2. Day 24 to 18: settle ownership. Is the domain in the client's name? Are the accounts in the client's name? What has to change holder before the transfer? This week decides the rest.
3. Day 17 to 12: secure and export the data. Database dump, files, measurement series, report archive. Every export is opened once and noted in the table with scope and date.
4. Day 11 to 7: run the transfer. Request the auth code and pass it on, create the zone at the new operator, lower the time-to-live values beforehand, provide the certificate on the target side.
5. Day 6 to 2: counter-check. Measure name records, address, delivery, certificate, mail sending and verification records; correct every deviation while both sides are still reachable.
6. Day 1 to 0: close the record. Enter the states, set the deletion date, name the open items, confirm on both sides. What starts after that is the deletion period, not a search for accounts.

A maintenance window for the transfer itself does no harm even when nothing technically goes down: it sets an expectation that everyone would otherwise form on their own. How such a window is announced and represented correctly in technical terms is described in the article on maintenance windows with 503 and Retry-After.