When changing a website maintenance provider, recover four groups of assets—control, the site itself, data and external services, plus licenses and documentation—twelve items in all. In practice, the domain, DNS, and company email fail most often. A verbal handover is not enough; the site must run fully in the new environment before the transfer is complete.
A company recently said its original builder’s engagement was about to end and it wanted a new partner for ongoing maintenance and changes. That differs from a vendor who has vanished: you can still reach them, so there is time to finish the transfer properly. This article is for that window. If the original vendor can no longer be reached, treat it as a lost-contact takeover rather than a normal handover.
Read the contract before notice
The most common mistake is announcing that you will not renew, and only then listing what you need back. Cooperation may drop, and you may not yet know what you are entitled to demand.
Before giving notice, find the contract and the quotation and check these four points:
- End date and notice period: How early must you notify? Does silence trigger automatic renewal?
- Delivery scope: Does it state how source code, the database, and documents will be handed over?
- Copyright and usage rights: Who owns the work after completion, and how may you use and modify it?
- Transfer fees: Is export or migration billed separately?
If the contract does not assign economic copyright, Article 12 of the Copyright Act generally gives those rights to the commissioned party when ownership was not agreed, while the commissioning party may still use the work. Rights sitting with the vendor therefore do not mean you cannot keep using the site; what you may do, and whether you can obtain the source, still depends on the contract and the case. If the amount is large or a dispute has already started, have a lawyer review it first.
Leaving rights with the builder is not always a disadvantage. What matters is whether use, modification, and later maintenance by another vendor were written down in advance. Read those clauses carefully.
Twelve items to recover
Items 1 to 4 are control, 5 to 8 are the site itself, 9 and 10 are data and external services, and 11 and 12 are licenses and documents. Print the list and tick each row.The column that defines “actually received” matters most: vendors often say an item was delivered when they only shared an under-privileged account.
| Item | What counts as received | If it is missing |
|---|---|---|
| 1. Domain control | Your company is the registrant and can sign in at the registrar | The address may expire or cannot be transferred |
| 2. DNS control | You can edit records and export every setting | The host cannot be switched, and mail may fail |
| 3. Host or cloud account | You have admin rights and can download every file | Code and the database cannot be retrieved |
| 4. Company email | You know where mail lives and hold an admin account | Incoming mail may stop after the switch |
| 5. Full source | Code, layout, plugins, and dependencies are listed | The new team cannot modify or rebuild the site |
| 6. Database backup | The latest full backup imports with nothing missing | Customer data, orders, and pages may disappear |
| 7. Uploaded files | Images, PDFs, and user uploads are all included | Image links fail across the site |
| 8. Top admin account | You can create and remove other administrators | You can edit content but not manage access |
| 9. Google and ads accounts | GA, Search Console, the business profile, and ads all have admin access | Past traffic and ad history cannot move with you |
| 10. Payments, logistics, SMS, and mail | Accounts belong to your company, and every API key is listed | Checkout and system notices may stop |
| 11. Paid license proof | Fonts, stock assets, and paid plugins show the licensee and term | Licenses may expire or cannot be transferred |
| 12. Technical notes | Environment versions, jobs, integrations, and the SSL expiry date are documented | The new team must rediscover every setting |
Item 4 is the one most often skipped.Company mail sometimes shares the same server as the site, or the same vendor manages both.If you move only the website, discovering later that customer mail no longer arrives can hurt more than a site outage.
Accounts should return to your company’s name, not pass directly from the old maintainer to the new one. Otherwise the same problem returns at the next change.
Six questions to confirm
Some vendors cooperate; others delay with vague replies. Put the questions below in writing. The answers show whether the handover will go smoothly.
| Question to confirm | A solid answer | An answer to watch |
|---|---|---|
| Who is the domain registered to now? | They share the lookup result and registrar login | “It is easier if it stays with us” |
| What does the source delivery include? | They list the scope and explain plugins and packages | “It is all on the server; download it yourselves” |
| When was the backup taken? | They give the date and will back up again before the switch | “We backed it up sometime before” |
| Which external services are connected? | They list each service and which company owns the account | “We will only know on handover day” |
| Is the transfer billed separately? | They list tasks, hours, and fees | “We will see later” |
| Can they help if the new environment fails to restore? | They state the scope and time limit of help | “Once the files are sent, we are done” |
Keep the tone even. The more complete their information, the better for you. If unpaid invoices remain, reconcile them first; an unsettled bill often stalls the handover.
Five steps in fixed order
The rule for sequence is: secure control first, move data next, and switch last. Start about 60 days before the contract ends. Start earlier if the site is complex or includes members or payments.
- Review the contract and current state (about 60 days out): Mark what you already hold and what is still missing against the twelve items.
- Recover control (about 45 days out): Handle the domain, DNS, host, and email first, then formally request the remaining deliverables.
- Take a full backup (about 30 days out): Obtain the source, database, and uploads, and store them in space your company owns.
- Restore in a new environment (about 21 days out): Have the new maintainer rebuild on a test environment and check forms, login, checkout, and mail one by one.
- Switch and close out (before expiry): Lower the DNS TTL at least a week ahead (the cache time before a record change takes effect), back up once more before the cutover, and confirm both the site and mailboxes afterward.
Step 4 cannot be skipped. Having the files does not mean the new environment will run: restores often lack config files, mismatch plugin versions, or hit an outdated host. Find those gaps early, while the old vendor is still available to fill them in.
When changing hosts, aim for as little downtime as possible and run a separate check.
Finish access and data cleanup
Do not tear down the old host the moment the new site is live. Keep it for a while, until traffic there falls to zero and you are sure no files or scheduled jobs were left behind, then shut it down.
After the site is stable, finish these five tasks:
- Remove old access: Strip the former vendor’s logins from the admin panel, host, DNS, Google, and ad accounts.
- Reset passwords and keys: Replace admin passwords, database passwords, and API keys.
- Delete personal-data copies: If the site holds members or orders, get written confirmation that the old vendor deleted its copies and backups.
- Check jobs and notices: Automatic backups, outbound mail, and SSL renewal must run normally in the new environment.
- Update the asset list: Record all twelve items, name an internal custodian, and do not leave them only in one colleague’s inbox.
This last step matters. Many handovers are painful because nobody maintained an asset list for years.
Three common mistakes
1. Starting only two weeks before expiry. With too little buffer, files are moved first and gaps appear after launch, when the old contract may already have ended.
2. Leaving the entire transfer to the new maintainer. They can advise and execute, but the contract, domain registrant, and company accounts remain your decisions. Some steps only your company can take.
3. Handing over files without knowledge. Examples include when a job runs and why a feature was built that way. Ask the old vendor for notes, or hold one handover meeting, so the new team does not have to guess from scratch.
Avoid dependence on one vendor
Changing maintainers is a chance to put control of the site back in order. Keep these three points in mind:
- Register key accounts to your company: Confirm the domain, DNS, host, and email first, so the next vendor change does not start over.
- Accept the work only if the new environment runs: Files alone are not enough; a working restore is the finish line.
- Start at least two months before expiry: That leaves time to find gaps and ask the old vendor to fill them.
Day-to-day maintenance can sit on a separate checklist. If you already have a status list but are unsure what is missing, or whether to take over or rebuild, clarify the conditions before deciding. That usually points the way faster than continued guessing.
