Sooner or later, the existing care for a shop comes to an end: the provider shuts down operations, a contract expires, the familiar contact moves to another employer -- or the working relationship simply fades away without anyone formally ending it. The shop keeps running on the surface, but nobody applies updates any more, nobody checks backups, nobody responds to alerts. This is exactly the state in which the damage builds that becomes visible later: German businesses reported 289.2 billion euros (Bitkom) in total damage for 2025, of which 202.4 billion euros (Bitkom) came from cyberattacks. A maintenance handover is therefore not a formality but a project with its own sequence. This guide shows which access and ownership inventory belongs to it, what is genuinely reviewed in the first 30 days, and how the transition produces a handover record and a runbook -- as the basis for ongoing care of an online shop.
Key takeaways
- A shop without care ages measurably: Germany's federal cyber security authority most recently counted an average of 119 new vulnerabilities (BSI) worldwide per day, an increase of around 24 percent (BSI) over the previous reporting period.
- The handover starts with ownership, not technology: domain, DNS, hosting, repository, licences and payment and shipping accounts belong in an inventory of roughly twelve items.
- Service providers are part of the attack surface: a third party was involved in 30 percent (Verizon DBIR) of the breaches analysed -- twice as often as the year before at 15 percent (Verizon DBIR).
- The first 30 days are for stocktaking, not rebuilding: version and patch levels, deviations from the shipped state and a genuine restore test come before any optimisation.
- The handover produces two documents: a handover record with findings and deadlines, and a runbook that lets a stand-in keep the shop running.
Why a provider change is a project step of its own
A shop that keeps running without care looks unchanged from the outside. Inside, it ages. Germany's Federal Office for Information Security counted an average of 119 new vulnerabilities (BSI) worldwide per day in IT systems in the reporting period from July 2024 to June 2025, around 24 percent (BSI) more than in the period before; observed exploitation activity rose by 38 percent (BSI) over the same period. Every week without an applied security update therefore widens the gap between the state of your shop and what attackers already scan for automatically. The backlog does not grow linearly but in jumps: skip three minor versions and you can no longer simply apply the next update, you have to catch up a chain of intermediate steps -- a pattern we describe in detail in our article on handling vulnerabilities and CVE advisories.
The second reason lies in the dependency itself. In the Verizon Data Breach Investigations Report 2025, a third party was involved in 30 percent (Verizon DBIR) of the breaches analysed -- twice as often as the year before, when the share stood at 15 percent (Verizon DBIR). Service providers, extensions and hosting partners are part of the attack surface, and a change of provider is the moment when that chain becomes fully visible once. Documenting it cleanly at this point yields more than credentials: for the first time you get a dependable answer to the question of who can actually reach which part of the system. Which services should be covered contractually afterwards is set out in our article on what a maintenance contract should include.
What this article means by maintenance handover
The access and ownership inventory
Before any technical review comes a commercial question: what actually belongs to you? In practice this is less clear-cut than merchants assume. The domain is registered in the agency's name, the hosting contract runs through their collective account, extensions are licensed to a provider account, and the repository sits under an account nobody in house can reach. An inventory therefore separates three things consistently: who legally owns an item, who administers it technically and who is able to log in. Only when all three columns are filled is the starting position clear. Domain and name resolution matter most here, because availability, certificates and mail delivery all hang off them -- why they deserve dedicated protection is shown in our article on DNS maintenance, DNSSEC and registrar lock.
Domain and registrar
Owner data, registrar access, the auth code for a transfer and the registrar lock. If the domain is not in your name, everything else is secondary.
DNS management
Zone file, TTL values and the records for mail delivery and certificate validation. Without access here, you cannot steer a migration.
Hosting and server
Contractual relationship, console access, SSH keys and database credentials. It also matters which other projects share the same environment.
Repository and deployment
Source code, version history and the pipeline that pushes changes live. Without history there is no answer to the question of when what was changed.
Licences and extensions
Licence holder, terms and sources for each extension. Licences in someone else's name expire after the change and cannot be renewed by you.
Payment and shipping
Merchant accounts, API credentials and webhook targets at payment and shipping services. They hang off contracts that rarely travel with the shop.
Six further items are regularly overlooked during a handover because they are invisible in daily business and only surface when they fail. This applies above all to everything that runs automatically in the background: certificate renewal, mail delivery, monitoring and backups. That automation is the part the previous provider typically ran on their own systems -- and it leaves with them. Just how tight the deadlines have become is made clear in our article on shorter TLS certificate lifetimes and their automation.
- Mail delivery: which account does the shop use to send order and system mail, and who owns it?
- Certificates: where does automatic renewal run, and who is warned when it fails to happen?
- Monitoring: which checks are active, which addresses receive alerts, and who acknowledges them?
- Backups: where are they stored, how long are they kept, and who is able to restore them?
- Analytics and consent: which tools are embedded, and through whose account do they run?
- Legal texts: who maintains imprint, privacy policy and withdrawal terms, and with which login?
When the credentials sit with the previous provider
The most common finding on day one is this: the merchant has one login to the shop backend and nothing else. Server, DNS, repository and licence accounts sit with the previous provider. That is uncomfortable but rarely hopeless. The orderly route starts with a written, politely worded request that names precisely which items are to be handed over and by when. A list helps more than a general plea for credentials: it makes the handover tickable and documents what was requested. In parallel it is worth reading the contract, because many maintenance agreements explicitly regulate cooperation at the end of the term.
If no response arrives, several independent levers remain. For domains the route runs through the registrar: as the registered owner you can request the auth code and initiate a transfer, even without the technical contact's cooperation. If the owner data is wrong, a change of registrant is the preceding step. For hosting, what counts is who the contracting party is; if the contract runs through the provider, rebuilding the environment is often faster than negotiating. Data protection law helps as well: under Art. 28(3) GDPR (GDPR) the processor must delete or return personal data at the controller's choice once the service has ended. A record of processing activities under Art. 30 GDPR (GDPR) additionally lists which providers are involved at all -- often the fastest source for a complete inventory.
Ownership is not the same as access
The first 30 days: stocktaking instead of assumption
After the access phase comes recording the actual state. The temptation to start tidying immediately is strong -- yet anyone who reviews and changes at the same time in the first month can no longer attribute a later fault to a cause. So a simple rule applies during a handover: measure first, act second, with acute security gaps as the only exception. Recording covers version and patch levels of core, extensions, PHP and database, along with their support deadlines. An expired language runtime is no side issue here; it shifts the entire update path, as our article on handling the end of support for PHP shows. All checks run read-only on the live system, and write access happens only in a separate staging environment.
| Review area | What is often reported | What the handover verifies |
|---|---|---|
| Backups | Backups run daily | Restoring a backup into a test environment, with the time measured |
| Version level | The shop is up to date | Core, PHP and database versions matched against support deadlines |
| Core customisations | There are none | File comparison against the unmodified shipped state |
| Extensions | Everything is licensed | Licence holder, term and source for each individual extension |
| Background jobs | They run reliably | Last successful execution per job looked up in the logs |
| Credentials | We have every login | Each credential used once to actually sign in |
- Collect the credentials, use each one individually and renew the passwords immediately afterwards.
- Clarify ownership: in whose name do domain, hosting, licences and merchant accounts run?
- Record version and patch levels of core, extensions, PHP and database and compare them with support deadlines.
- Look for deviations from the shipped state and describe each undocumented customisation rather than removing it.
- Restore a backup into a test environment and measure the actual recovery time.
- Rank the findings by urgency, close acute gaps at once and turn the rest into a roadmap with dates.
Backup reality instead of backup claims
Hardly any point diverges from expectation as often during a handover as data backup. Almost everywhere some kind of backup exists -- the question is whether it contains the right things, whether it is readable and how long restoring it takes. Typical findings: the database is backed up but not the file directory holding images and uploaded documents. Or the backup sits on the same server, so a compromised system loses both at once. Or retention reaches back seven days while a silent data error only surfaces after three weeks. Which combination of cadence, storage location and retention holds up is set out in our article on backup strategies for online shops.
The decisive step is therefore the restore test. Only it answers the question that counts in an emergency: how long can customers not place orders? That time is a metric, not a feeling, and it can only be determined by a genuine attempt. Once you know that a full restore takes, say, four hours, you can build a recovery plan on it, as described in our article on restoring a shop after an outage. The economic background is well documented: the global average cost of a data breach was 4.44 million US dollars (IBM) in 2025, and it took an average of 241 days (IBM) to identify and contain an incident. Both figures drop noticeably where a tested recovery path exists.
- Are files and database both backed up, or only one of the two?
- Does the backup sit separately from the production system and out of the shop's reach?
- How far back does retention reach, and does it match commercial record-keeping periods?
- How long does a full restore take -- measured, not estimated?
- Who is allowed to trigger a restore, and is the procedure written down?
- When did the last restore test take place, and where is its result recorded?
Handover record and runbook
A handover is only complete once its result is written down. Two documents with different purposes come out of it. The handover record fixes the cut-off date: which credentials were transferred, which are missing, which findings were raised, what was fixed immediately and what is scheduled by when. It is a document with a date and a signature line and later serves as evidence of the state in which the shop was taken over. The runbook, by contrast, is a living document: it describes operations so that a stand-in can work without asking questions. Precisely this traceability is also what makes it possible to look after several projects in parallel -- a principle our article on outsourced care for client projects under your own brand describes for agencies.
# Runbook shop.example -- as of 24 August 2026
# Business owner: merchant / technical owner: maintenance team
## 1 Access and ownership
- Domain and registrar: owner data, auth code procedure, registrar lock active
- DNS: zone, TTL values, who may change records
- Hosting: provider, contract number, console access, stored SSH keys
- Repository: address, branch model, list of people with write access
## 2 System state
- Shop core: version, date of the last update
- Deviations from the shipped state: file, reason, responsible person
- PHP and database: version, end of vendor support
- Extensions: name, licence holder, term, source
## 3 Recurring tasks
- Backups: cadence, storage location, retention, last restore test
- Background jobs: name, cadence, expected runtime, alert if missing
- Certificates: renewal path, remaining validity, alert on failure
## 4 In case of an incident
- Availability and agreed response time per maintenance contract
- Rollback path: last working version, order of restart steps
- Reporting: who informs customers, payment providers and authorities
A bus factor of one
Typical pitfalls after the switch
Most faults after a handover do not arise in the shop itself but in the automation around it. It fails without reporting an error: a cron job simply stops running, a certificate renewal does not happen, a system mail goes out through an account that has been cancelled. Such failures often stay unnoticed for weeks because the shop remains reachable and only one part falls silent. How to make these silent failures visible is described in detail in our article on monitoring cron jobs and imports.
Decommissioned background jobs
Price imports, stock synchronisation and cleanup runs lived on the old provider's system. They are gone after the switch without producing an error message.
Expired certificate automation
Automatic renewal hung off someone else's account or script. The failure only shows once the browser flags the site as insecure.
Mail through third-party accounts
Order and password mails run through a login held by the previous provider. Once it is switched off, system mail disappears without a visible trace.
Undocumented customisations
Changes made directly to core or theme do not survive the next update. Without documentation there is no hint about what behaves differently afterwards.
Orphaned alert routes
Monitoring messages keep going to addresses nobody reads any more. The alert fires and is still seen by no one.
Licences in another name
Extensions are licensed to a provider account. Once the term ends there are neither updates nor support, and repurchasing is the only route.
Mail delivery deserves particular attention here, because it touches two levels at once: the technical sending path and the reputation of the domain. If the sending path changes without the corresponding records in name resolution being adjusted, order confirmations land in the spam folder -- and the merchant learns about it through customer calls. Which records have to line up and how the state can be monitored is described in our article on the deliverability of shop email. Orphaned alert routes are similarly invisible: monitoring whose messages go to a cancelled mailbox is, in effect, no monitoring at all.
Offboarding: cleanly withdrawing old access rights
The last step is forgotten most often, because by then everything is running again: the previous provider's access rights stay in place. Sometimes out of courtesy, sometimes out of fear of breaking something, mostly simply because nobody thinks of it. The risk is concrete: the use of stolen credentials was the first step of an attack in 22 percent (Verizon DBIR) of the breaches in the Verizon Data Breach Investigations Report 2025, and ransomware was involved in 44 percent (Verizon DBIR) of all breaches analysed. To the system, an old credential looks no different from a current one. How to renew technical keys methodically is described in our article on rotating API keys and secrets.
- Deactivate rather than delete the previous provider's user accounts in the shop backend, so the audit logs stay traceable.
- Remove SSH keys, console and database credentials belonging to the old team, then renew the remaining keys.
- Rotate API keys and webhook secrets at payment, shipping and inventory management services.
- Withdraw write access to repository, deployment pipeline and artefact storage, and secure the history.
- Check forwarding rules and shared mailboxes through which system mail still reaches the old provider.
- Record every withdrawal with date, affected credential and the person who carried it out in the handover record.
The same standard applies to the remaining accounts as to new ones: as few people as possible, permissions as narrow as possible, two-factor authentication for every administrative login. How thoroughly attacks are prepared is shown by one figure from the BSI situation report: sensitive information was publicly visible behind 47 percent (BSI) of the reachable IP addresses under .de domains, including hints at possible vulnerabilities. Attackers search for such traces automatically before they try a single credential. Which methods hold up in daily shop operations is summarised in our article on securing shop admin access with multi-factor authentication.
From takeover review to ongoing care
The handover itself is a one-off service with a clear scope: access and ownership inventory, stocktaking of version levels, customisations and backups, a restore test and the two documents at the end. The effort depends on the number of systems, the extent of customisation and the state of the existing documentation; in our experience it amounts to one to three person-days for a typical shop. We quote that range up front as a fixed price so the stocktaking does not remain an open item. Only afterwards is it decided what belongs in regular operations -- and at which cadence. That cadence is fixed by an SLA maintenance contract: response times, service hours and the scope of recurring work are set down in writing.
What runs permanently afterwards is the opposite of the state before the handover: security updates on a fixed rhythm, verified backups, continuous monitoring with alert routes someone actually reads, and a runbook that keeps being updated. The distance from the starting position is economically measurable, since according to Bitkom 59 percent (Bitkom) of the companies surveyed see their commercial existence threatened by cyberattacks, while only 50 percent (Bitkom) rate themselves as very well prepared. That gap is not closed by a one-off project but by a dependable cadence.
Maintenance that exists only in one person's head is not maintenance but a risk with holiday entitlement. A change of provider is the cheapest opportunity to write it down.
If your current maintenance is running out or has effectively stopped, getting started is straightforward: you briefly describe which credentials are available and how contact with the previous provider stands. Those two answers alone indicate whether the handover is a matter of weeks or of days. We settle the right scope in a first conversation about the maintenance handover -- the outcome is a shop whose credentials are clarified, whose state is documented and whose care is staffed again.
Sources and Studies