Start a developer handover by listing the website's systems, the business's rights and the access it needs. For an ordinary planned transfer, add the new access, check it works, then remove access nobody needs. Move hosting, the registrar or the platform only when there's a reason. If an account may be compromised, use an incident response instead of the normal sequence.
Changing developer is not the same as moving everything
A developer change is about who looks after the website. Every other change is a separate decision with its own reason and scope.
More than one can happen at once without any of them requiring the others. New URLs need their own assessment. So does a change to the domain's legal holder, called the registrant.
You can change custodians without moving the site at all. For how the pieces fit together, see our guide to running a small business website.
Handover problems have different causes. Each needs a different response:
Cause | Where to start |
|---|---|
Poor records | Build the register and fill the gaps |
A genuine contract issue | Review the agreement and get advice |
An unavailable person | Use existing admins and official recovery routes |
A security incident | Follow the incident route straight away |
Name who decides and who coordinates
Two providers making uncoordinated changes can undermine a transfer. That's true even when both have valid access. So name a business decision maker and a technical coordinator before work starts.
The decision maker approves each of these:
Decision | Why one person approves it |
|---|---|
Access changes | Stops two providers granting conflicting roles |
Spending | Keeps licences and overlap costs visible |
DNS changes | Protects email and connected services |
Code deployment | Stops providers overwriting each other's work |
Maintenance windows | Keeps disruption to agreed times |
Final acceptance | Confirms the business is satisfied with the result |
The coordinator sequences the work between the outgoing and incoming providers. Agree how both report changes and unresolved dependencies.
Keep a short change log
Don't assume the other provider knows what happened. Record each change, with who made it, when and why.
If you need an editing or deployment freeze, write down when it starts. Note any approved exceptions and who restarts normal work.
What does the business need to control?
The business needs proportionate control and a documented way to continue or exit. Our view is simple. You hold the keys. Your providers hold logins. Several different roles can attach to one website:
the domain registrant, who holds the domain licence
the holder of each service account
the person paying each bill, who may hold no access at all
administrators who hold technical permissions in each system
the owner of the intellectual property (IP) in custom work
a software licensee, who has permission to use a product
A business can pay for a service without holding every permission. Software ownership is separate again.
Here, you means the business. Shared means the business and the provider who maintains that layer. These are suggested roles, not a finding about any setup or a substitute for your contract.
The domain is a licence
A .au domain is a licence with eligibility rules. The registrant is the person or entity that holds it. The registrar manages it in the .au registry, sometimes through a reseller.
auDA's transfer rules treat the two changes differently. A registrant change moves the licence to another eligible holder through the current provider. A registrar change moves the management of the same licence.
Domain control helps with some recovery processes. It isn't a master key that recovers every platform.
Paying for work doesn't settle every right
IP Australia says IP created by a contractor belongs to the contractor unless the contract says otherwise. So check the written agreement for:
ownership and assignment of custom work
licences and modification rights
the deliverables that must be handed over
Treat custom code, third party components and source design files separately. An invoice alone doesn't prove every right transferred.
Agency licences and hosted services may not be transferable. You might need a replacement licence or a different support arrangement. The reverse is also true. Access to a repository or password doesn't settle a rights dispute.
Read the agreement before you act
Review the agreement for:
termination notice and handover obligations
data return, including exports and backups
hosting and support terms
payment disputes and agreed fees
ongoing licences and who holds them
Applicable law can affect contract terms. The ACCC's contracts guidance explains that unfair contract terms laws protect small businesses in standard form contracts. Small business here means fewer than 100 employees or under $10 million turnover. The protections cover contracts made or varied from 9 November 2023. Only a court can decide a term is unfair.
Don't ignore an invoice or pay a disputed demand on this guide alone.
Be specific. Ask for the site's authorised assets and access, or an agreed migration. Don't ask for other customers' data or the provider's master credentials. Reseller accounts need care. A shared one may not transfer as a whole.
Build an ownership and access register
A register is one record of every service the website depends on. Create one row per actual service or account, not one per password.
Use the seventeen systems below as prompts. You may have several accounts in one category and none in another. Treat the register as sensitive and share it only with the people who need it.
These are the columns to include:
Field group | Columns |
|---|---|
Identity | Asset ID, category, purpose, provider, account URL, account or property ID |
Rights and control | Business entity, contract reference, business administrator, backup administrator |
Supplier access | Outgoing access, incoming access, required permission, verification date |
Recovery and billing | Recovery contact, MFA custodian, billing owner, renewal date, recurring cost, tax basis |
Dependencies and work | Connected services, status, required action, action owner, due date |
Evidence and closure | Evidence reference, acceptance result, access removal date, retention or deletion decision |
MFA is multi factor authentication, the second check after a password. The recovery contact and MFA custodian are the people responsible. They're never the secret itself.
Give every row one status:
Status | What it means |
|---|---|
Confirmed | Rights and access checked, with evidence |
Missing access | The business can't reach the account yet |
Transfer required | The account or role has to move |
Replacement required | A new licence or service is needed |
Under review | Facts, rights or terms are still being checked |
Not applicable | The system doesn't exist for this business |
Keep status separate from severity and from the acceptance result. Never mark unknown rights or access as confirmed.
Never put these in the register:
passwords or domain transfer codes
API secrets, the keys systems use to talk to each other, or private keys
recovery codes or MFA seeds
customer records
Point to the item in your password vault instead. Each entry follows the same pattern:
Asset: [category, purpose, provider and account ID]
Rights: [business entity and agreement reference]
Business control: [administrator, backup contact and recovery custodian]
Supplier access: [outgoing, incoming and required permissions]
Billing: [owner, renewal, cost and tax basis]
Dependencies: [connected services and vault reference]
Action: [status, owner, deadline and required evidence]
Acceptance: [test result, approval and closure date]
It's a blank template, so keep secrets and client data out of it. Here's how four fictional entries might look:
Fictional asset | Status | Next action |
|---|---|---|
Domain whose business contact needs checking | Under review | Confirm the registrant contact email |
Hosting billed through the agency | Under review | Check the hosting terms in the contract |
Tag Manager with one agency admin | Missing access | Add a business admin and a backup |
Premium plugin on the agency's licence | Replacement required | Buy a licence in the business's name |
A spreadsheet works well, with the columns above copied into three tabs:
Instructions, explaining both routes, each status, how to record evidence and who can see the file
Register, one row per system
Acceptance, using the acceptance record below, plus a test ID, evidence link and blocker column
What to collect before changing developers
Collect these seventeen systems before anyone changes access. The numbering helps you work through the inventory in order. It isn't a ranking of risk.
Group | Systems |
|---|---|
Infrastructure | 1 domain name, 2 DNS, 3 hosting, 4 CMS |
Day to day operations | 5 files and database, 6 transactional data, 7 business email, 8 forms and delivery |
Analytics and marketing | 9 GA4, 10 Search Console, 11 Tag Manager, 12 advertising and marketing platforms |
Assets and connections | 13 design files, 14 source code, 15 licences, 16 integrations, 17 documentation |
System 1: the domain name
Record these details for the domain:
the registrar, and the reseller if there is one
the registrant named on the licence
the renewal date and who pays for it
the recovery contact for the domain account
current nameservers, the servers that answer for the domain
Check the business's actual entitlement. Then check its account access. If the registrar must change, use the current provider's transfer process.
That process needs an authorisation code, often called the EPP code. According to auDA, the code is unique to each licence. It's separate from your account password, so keep it out of the register. A registrar change doesn't move email or the website.
System 2: DNS
DNS is the domain's address book. It tells browsers and mail servers where each service lives. Preserve the complete zone, meaning every record. Note which provider is authoritative, the one whose servers hold the official records.
Include these records where they exist:
A and AAAA records, which point names at servers
CNAME records, which point one name at another
MX records, which route incoming email
TXT records, which hold email policies and verification codes
CAA records, which limit who can issue certificates
any other service records your tools use
Note any DNSSEC setup too. DNSSEC signs the records so resolvers can check they're genuine. Document why important records exist. A public lookup isn't always a complete list.
DNS carries more than the website. It may also point to a CDN, a network that serves cached copies of the site:
A nameserver change needs a complete planned zone at the new provider. The website address alone isn't enough.
DNSSEC adds a step, because the parent zone holds a DS record that must match the signing keys. For a move to Cloudflare, its DNSSEC guide describes two routes. One turns DNSSEC off at the registrar before the move. The other keeps it on while both providers sign the zone. That only works if the old provider supports it.
Change nameservers too early and validating resolvers can fail to load the domain. Follow your providers' supported procedure. There's no universal rule to turn DNSSEC off.
System 3: hosting
Record these details for the hosting account:
the account holder and the plan you're on
billing, and the software versions the host supports
storage, databases and staging copies, the test versions of the site
backups, HTTPS, CDN and firewall
scheduled tasks and support access
Then decide whether the incoming provider can maintain the current setup. A new developer doesn't, by itself, justify a host move. If a move is proposed, see assessing the proposed hosting.
Check who owns certificate renewal as well. Our guide to HTTPS configuration and renewal ownership covers that side.
System 4: the CMS
The CMS is the editing system behind the site. Record the platform, the site or store owner and the named roles.
Roles differ between platforms. On WordPress, an Administrator has every administration feature on a single site. A hosted builder contributor or a store owner role works differently. Use each platform's supported invitation or transfer process. Keep a business recovery route, and check the permissions match the agreed work.
Our guide to the website's CMS and roles explains the basics. Before cutover, check two recovery dependencies:
whether the only recovery mailbox sits on an account being cancelled
whether MFA sits on the departing person's phone
Fix those first, or the business can lock itself out while taking control.
Backups, live data, email and forms
These four systems keep the business running day to day. Each one can break quietly during a handover.
System 5: website files and database
A typical self hosted WordPress restore needs both the files and the database. WordPress's backup guide treats them as two separate parts. Keep the required configuration and custom components too.
Record the backup's time, scope and location. Then record who can reach it and the restore result. A CMS export isn't automatically a full backup.
Test the restore in a protected copy of the site. Stop that copy sending customer email, taking payments or firing live webhooks. A webhook is an automatic message one system sends another when something happens.
A download isn't a restore. A common mistake is copying the WordPress files without the database. For platform limits, see creating and testing a recoverable backup.
System 6: current transactional data
Orders, bookings and customer records keep changing while a site moves. One system has to be the reference point:
Identify the authoritative system for each kind of record:
orders and bookings, including payment states
memberships and subscriptions
inventory and stock levels
customer records and account logins
Then agree a data cut off and the final export or sync method. Add an exception log and name who reconciles the results. Brochure sites change too. New enquiries or edits can arrive while a copy is being moved.
Plan for activity after cutover. If the new site takes orders and then needs recovery, don't restore the old database over it. Preserve the new records and reconcile them using the agreed method. Prevent duplicate charges, fulfilment, messages and stock movements.
System 7: business email
Record these details for business email:
the email service and its tenant administrator
mailboxes, aliases and groups
forwarding rules that send mail elsewhere
billing and the recovery contact
sending setups for newsletters and apps
Trace where the MX records point. Check whether mail depends on the old web server or host. Then preserve the email authentication records:
SPF, a TXT record listing who may send for your domain
DKIM, a signature check published as TXT or provider CNAME records
DMARC, a TXT policy for failed checks
Microsoft 365, for example, uses two CNAME records for each domain's DKIM. So don't copy every old record blindly into a different sending setup.
The SPF standard says a domain must not publish more than one SPF record. Your technical owner should check the intended setup against the mail provider's current instructions.
Changing only a web record can still affect email. Mail routing or a sending service may depend on that hostname or server. Trace the actual dependencies, then test sending and receiving after the change. A common mistake is changing nameservers without copying the email records.
System 8: forms and email delivery
Record these details for each form:
the form tool and where entries are stored
recipients and confirmation emails
the mail service that sends them
CRM routing and spam controls
consent and privacy notices
Test the complete enquiry path on desktop and mobile. A known test entry should reach the responsible person. See checking enquiry forms and delivery.
Use made up test data with the right permissions. Don't copy patient, financial or customer records into a casual staging site. Don't send them in a handover email either. Our guide to handling customer information during the handover covers the privacy side.
Analytics and marketing accounts
Google's products each use their own permission model. Ownership in one doesn't carry over to another.
Here, you means the business holds the role directly. Shared means an agency's manager account or billing can connect to an account the business holds. Incoming suppliers get the permissions their work needs.
System 9: Google Analytics 4
Record these details for each property:
account and property names
data streams and measurement IDs
key events and integrations
business administrators and any agency users
a reporting baseline to compare against after the change
Keep the existing property where it suits the business. Creating another one doesn't delete the old property. It does split your reporting between two records. A common mistake is creating a new GA4 property because recovering access feels hard.
If the account structure must change, Google supports moving a property between accounts. You need Administrator and Editor roles on both. Reporting data moves with the property. Earlier change history stays with the source account.
Review permissions and product links after any move. Our guide to keeping GA4 useful and correctly configured covers the setup.
System 10: Search Console
Keep verified ownership with the business. A verified owner proved control with a token, like a file or DNS record. Add the incoming provider at the level their work needs.
Google's permissions guide warns about removing every verified owner. Everyone else then loses access after a grace period.
When an owner leaves, check tokens as well as users. A removed owner's token isn't deleted. They can use it to verify again.
The same token can serve other services, though. Deleting it can break them. Replace those dependencies before removing the token. See verifying business access to Search Console.
System 11: Tag Manager
Tag Manager holds your tracking tags in a container. Confirm at least two active account administrators, including someone inside the business. Then document container permissions and export the configuration you need.
Google's Tag Manager permissions page explains the stakes. An account or container with no admin is deleted automatically. Users with read access then have 30 days to export from the trash. If nobody can read it, you start over and retag the site.
Google blocks removing every admin in the normal interface. An account can still lose its only admin if that person's Google account is deleted elsewhere.
An export holds the configuration only, not analytics history or every outside dependency.
System 12: advertising and marketing platforms
List each platform connected to the website:
Google Ads and Microsoft Advertising
Meta Business Portfolio and LinkedIn
CRM and email marketing tools
call tracking and review tools
product or listing feeds
Record each one's asset ID, business roles and agency links. Note what it depends on from the website. The web developer only needs permissions their work justifies.
Before unlinking a Google Ads manager account, check who provides conversion tracking, shared audiences and billing. Google says the customer account keeps its own campaign history. Unlinking can still change three things:
the manager's shared conversion tag stops recording new clicks
lists relying on that tag stop filling
if the manager pays on monthly invoicing, ads stop serving unless billing changes first
Coordinate with whoever manages your advertising. Their side is covered in Google Ads management responsibilities and call tracking ownership and continuity.
For the Business Profile, do four things:
keep the existing legitimate profile rather than creating a duplicate
confirm the business holds primary ownership
plan around Google's 7 day wait before new owners or managers can use every feature
if someone else controls it, use Google's ownership request route. The owner then has 3 days to respond
Our guide to managing the existing Business Profile has more.
Then test the tracking. Check collection and destination IDs before and after the transfer. One tag firing doesn't prove consent, attribution or real outcomes work. Don't reconfigure marketing tools just so the new provider owns them.
Files, code, licences and integrations
The last five systems hold the assets and connections that are hardest to rebuild. Rights matter as much as access here.
System 13: design and source files
Collect the agreed design files, like Figma files, plus brand assets and logos. Include image masters, copy and video, with their rights and licence references. Add any agreed component libraries.
Don't demand material outside the contract. A rendered page doesn't include its editable source.
System 14: source code and repositories
A repository stores code and its history. Confirm the incoming team has authorised access and an authorised way to deploy. Then list what the incoming team needs to build and deploy:
relevant branches and release tags for the right version
build requirements and package dependencies
the deployment pipeline that publishes changes to the live site
environment variables and configuration, with secrets kept in the vault
A production ZIP file may leave out the source needed to rebuild the application.
Include machine access in the inventory too:
Machine access | What to check |
|---|---|
Deploy keys | Which repository each one opens, and whether it can write |
Machine accounts | Which server or service uses each one |
App installations | What each app can reach in the repository |
Outside build services | Which credentials they hold |
GitHub's deploy key guide explains that a deploy key attaches to a repository, not a person. It has no expiry date and stays active even if the person who added it leaves the repository. Deleting someone's account doesn't remove every automated credential.
System 15: themes, plugins, apps and licences
Paid components raise the question of who holds the right to keep using them:
Record these for each paid component:
who holds the licence, and its scope
renewal date and transfer rules
update and support entitlement after the transfer
the replacement plan if the licence stays with the agency
Open source code rights and a paid support subscription are different things. Don't assume an expired subscription disables a component instantly. Don't assume it keeps working forever either. A common mistake is assuming the agency's plugin licences belong to the business.
System 16: third party integrations
List every connected system, such as:
CRM and accounting tools that receive website data
payment and shipping services used at checkout
inventory and booking systems that sync with the site
chat tools and customer portals
For each integration, record these details:
Detail | Why it matters |
|---|---|
Owner and billing | Someone must keep approving and paying for it |
Where its secret is stored | Keys need rotating without breaking the link |
Purpose and webhook destination | Messages must reach the right system |
Scheduled tasks | Jobs may still run from the old server |
Support contact and a test | You need proof it still works |
Note machine access separately from human logins. That includes API tokens. It also includes OAuth grants, approvals that let one app act in another. Removing a person's login may leave these routes active.
System 17: existing documentation
Collect whatever documentation exists:
architecture and deployment notes
backup and recovery instructions
custom code details, including why it was written
maintenance history and known defects
renewal dates for every paid service
If documentation is missing, define discovery work and its limits. Don't declare the gap harmless because the site is small.
Start a baseline issue list too. It separates existing faults from transfer work. Agree the support scope, escalation process and open risks with the incoming provider.
Receiving access doesn't mean they've audited or accepted every inherited component. Our guide to auditing the inherited website can help with the baseline.
How to transfer the website in twelve steps
This is the ordinary planned route. Suspected compromise follows the incident route instead, covered further down.
The flow groups the twelve steps into six stages.
Choose the incoming provider and agree the task
Confirm what they'll do, what access they need and where support stops. Agree who approves changes. Our guide to choosing the incoming developer covers selection.
Review the agreement and exit obligations
Check the rights, notice and handover scope, then the fees, data return and licences. Get advice wherever something is disputed.
Complete the register and change plan
Identify missing control and any recovery dependencies that could lock the business out. Name who owns each piece of work and agree the communication channel.
Take and verify a recoverable backup
Record when the data was captured and how you'd recover it. A backup isn't a full migration plan.
Add named replacement access
Use invitations or a secure credential process, with a separate login for each person. Keep business administration in place.
Never share one master password between providers. A common mistake is removing the old developer before the new one has working access.
Verify access and required tasks
Get evidence of the actual permissions, including backup, deployment and support access where they apply.
Keep hosting or migrate for a documented reason
Moving hosts needs a documented reason. A platform or URL change needs its own scope.
The new provider must still be able to support the arrangement you keep. There are two cases.
Case 1, staying on the current host. Finish the permission, backup and licence work. Then complete documentation, support and acceptance. Skip DNS changes you don't need. Confirm support access and billing still work after the former provider leaves.
Case 2, moving hosts. Set up and test the new environment. Restore the site and its configuration, then check HTTPS. Google's hosting move guidance treats this differently from a URL migration. It suggests lowering the DNS TTL ahead of time, then watching server logs on both hosts.
TTL is how long resolvers cache a record. Test a private or protected copy first, covering:
important pages and downloads
forms and logins
checkout and integrations
Stop test orders, messages or webhooks reaching real customers. If URLs change as well, see protecting search visibility during a move.
Live data needs its own sequence:
Matching record counts don't prove the right records arrived. Take a store whose first copy holds 200 orders. Before cutover, three new orders arrive and one existing order is refunded.
The source now holds 203 order records. The refund changes an existing order's state rather than adding a record. So compare identifiers, values and statuses, not just the count.
Now suppose two more orders land on the new site before anyone considers a rollback. Preserve those records and payment states before restoring any database. The exact method depends on the store and payment systems.
The old server isn't automatically a safe rollback, because it may be stale or compromised. Plan recovery for the actual system.
Protect email and other DNS dependent services
Approve the exact DNS change set first. Agree the DNSSEC method, the validation checks and the recovery plan.
Allow for the previous TTL and cached answers. Then verify three things before calling it done:
the authoritative records at the DNS provider
answers from a few representative public resolvers
application and mail logs showing real traffic
Keep the old service only as long as the transition and recovery plan need it. No fixed number of days proves the change is complete. Nobody can check every resolver worldwide either.
Run the acceptance tests
Test real business journeys and admin tasks before checking search settings and measurement. The next section sets out the evidence.
Operate a controlled overlap
Watch the site, email and orders for a few days, and fix problems as they show up. Keep any recovery arrangement you might still need.
Remove obsolete access after acceptance
Remove the old provider's logins, keys and tokens, in an order that doesn't break anything still using them. The closing section lists what to check.
Confirm support and close the record
Test a backup restore and confirm who now owns billing and renewals. Record retention decisions and set a date to review the register.
How do you know the handover is complete?
The handover is complete when the business can run the agreed services without hidden former access. It should also be able to recover, or arrange support, on its own.
Area | Evidence needed |
|---|---|
Control | Business access and recovery work at the right level |
Website | Important pages, media, downloads and editing work |
Enquiries | A test enquiry reaches the right inbox or CRM, with the right confirmation |
Transactions | Orders or bookings, payments, stock and notifications reconcile |
Authorised messages send and arrive through the intended service | |
Search and measurement | Intended URLs, indexing, redirects and destination IDs check out |
Recovery | A dated backup and restore test support the plan |
Support and exit | Responsibilities, licences, billing, access removal and exceptions are recorded |
Record each result as pass, fail, unknown or not applicable, with evidence. A failed essential task blocks ordinary acceptance.
The decision maker can accept a documented minor exception with an owner and a deadline. That doesn't turn the failed test into a pass.
Task: [enquiry, booking, order, editing, recovery or reporting]
Baseline: [known state and inherited issues]
Expected: [observable result]
Observed: [actual result and evidence]
Tester: [name, date and environment]
Decision: [pass, fail, unknown or not applicable]
Exception: [approval, owner, deadline and remaining risk]
Retest: [result after any required fix]
Separate the baseline, the change made and the result observed. That shows which faults were inherited, without blaming every later fault on the transfer.
Sort every open issue into one of four groups:
inherited faults that existed before the handover
faults the transfer caused
exceptions the business has accepted, with an owner and date
future work that sits outside the handover scope
Log the dates. Note any other changes made at the same time. A common mistake is accepting the handover without testing checkout or bookings.
The complete handover checklist
Keep one checklist, grouped by area:
Group | Confirm |
|---|---|
Domain and infrastructure | Domain, DNS, hosting and HTTPS (systems 1 to 3) |
Website and data | CMS roles, files, database and live records (systems 4 to 6) |
Email and forms | Mail service, authentication and the full enquiry path (systems 7 and 8) |
Marketing | GA4, Search Console, Tag Manager, ads and Business Profile (systems 9 to 12) |
Assets and licences | Source files, code, licences and integrations (systems 13 to 16) |
Documentation and closure | Documentation, acceptance, access removal and the exit record (system 17) |
Use the same statuses as the register.
For the wider quality checks, run our website launch checklist.
Our free audit checks your access, ownership and setup before the handover, so nothing goes missing.
What if the current developer won't cooperate?
Start by working out what kind of problem you have. Missing access and an unavailable person need different responses. So do a payment dispute, a licence restriction and suspected malicious conduct.
Then work through these steps in order:
List the exact missing items.
Review the agreement.
Use any existing authorised administrators.
Contact the underlying provider, like the registrar or host.
Make a written request.
Handle commercial issues through the proper process.
Get advice where rights are genuinely disputed.
A written request should be specific and factual:
Business: [business name and website]
Agreement: [project or contract reference]
Requested items: [specific assets, roles and documentation]
Recipient: [authorised business or incoming provider contact]
Timing: [proposed date and coordination contact]
Transfer method: [secure invitation or approved file transfer]
Exceptions: [please identify any rights, licence or scope constraint]
Confirmation: [items supplied, remaining actions and dates]
It isn't a legal demand. Ask them to explain anything they say they can't supply or transfer. Don't ask for the agency's master account or other clients' data.
If the domain is involved
For .au domains, auDA separates two routes. Its complaints process covers eligibility and provider conduct. Disputes over legal rights to a licence go through the .au Dispute Resolution Policy (auDRP).
Neither route settles an unrelated website invoice or software IP claim. The transfer rules also block transfers while a licence is under a complaint or dispute.
Use official recovery channels
Use each platform's official account recovery process. Bring accurate evidence of identity and authority. Never bypass access controls or impersonate the provider. Don't use a former employee's login without authorisation.
Preserve agreements, invoices, correspondence and the technical access record. If deletion is threatened or valuable custom systems are contested, get advice promptly. A payment receipt alone may not convince a provider to transfer an account.
What if the developer disappears or it's urgent?
Three situations each get their own route below.
If the former developer has disappeared
Start from the accounts and evidence the business already controls. Identify the registrar and underlying providers. Secure any business administration you have. Then find authorised backups and work out what official processes can recover.
Domain control can support some verification methods. It doesn't recover every account, repository, secret or historical record. Record what's still unresolved. Only then estimate the cost of rebuilding what can't be recovered.
If the handover is urgent but cooperative
A time sensitive handover can compress the schedule. Both providers can prepare in parallel. If good records exist, the register comes together quickly. What doesn't shrink is the order. New access still gets added and verified before old access goes.
If you suspect a compromise
Active compromise needs a different route. Contain the damage, establish trusted administration and preserve evidence.
We must leave every old account active until the ordinary handover is finished
Normal transfers verify new access first. Suspected compromise needs immediate authorised containment and evidence preservation
Don't wait for the final offboarding step to revoke a malicious session or credential. The OAIC's breach response steps say to act immediately to limit a breach. They also warn against destroying evidence of the cause.
Avoid destructive cleanup. Containment may still need immediate changes, and that's fine. Record each incident action, its time and who authorised it.
Keep suitable logs and snapshots without spreading personal information unnecessarily. Then assess whether the old environment is safe to keep or use for recovery.
Keep email, enquiries and transactions running where you can. For the security response, see our WordPress access and security review. Domain, hosting and backups alone may not be enough to rebuild everything else.
Should you redesign during the handover?
Where practical, regain control and diagnose the existing site first. Combine the work only when there's a clear reason:
a demonstrated platform constraint
a required structural change
a migration you can't avoid
An old looking design or a new provider's preference doesn't, on its own, show you need a rebuild. Each extra change adds its own risk:
Change | Risk when combined | Check first |
|---|---|---|
Nameservers | Email or services stop resolving | Complete zone and DNSSEC plan |
Hosting | Missing files, settings or scheduled tasks | Tested restore at the destination |
Users | Lockout or leftover access | Business admins verified |
Licences | Lost features or updates | Licence holder and replacement plan |
Tracking | Gaps or duplicate measurement | Destination IDs tested |
Lost or rejected mail | Routing and authentication tested | |
Data | Orders or bookings lost between copies | Cut off and reconciliation agreed |
URLs | Lost search visibility | Redirect map and migration checks |
For the decision itself, see deciding whether a redesign is needed. For delivery, see delivering a planned redesign. If a platform change is on the table, try comparing a proposed platform change first.
What affects handover time and cost?
There's no universal number of hours or days. These factors can all stretch the schedule:
Factor | Why it adds time |
|---|---|
Access recovery | Official recovery routes have their own steps and waits |
Disputed rights | Advice and negotiation come before any transfer |
Undocumented code | Discovery work has to happen first |
Live data | Cut off, reconciliation and monitoring need planning |
Provider restrictions | Notice periods and waiting rules apply, like Google's 7 day wait for new Business Profile managers |
Replacement licences | New subscriptions need buying, installing and testing |
Acceptance work | Each business task needs evidence |
Here's the full working for the example:
Item | Calculation | Amount |
|---|---|---|
Discovery and handover work | 6 hours at $150 | $900 |
Replacement annual licences | One year | $240 |
Temporary service overlap | One off | $60 |
Ongoing support | 12 months at $120 | $1,440 |
First year total | All four items | $2,640 |
All figures are examples, in AUD excluding GST. They aren't Elev8d rates or Australian market averages.
The one off work, annual licences and overlap come to $1,200 before support. With the same rates and scope, a later year costs $1,680. That's the support plus the annual licences, with no new project work.
The example leaves out these costs:
redesign and new development
hosting beyond the stated overlap
email subscriptions and domain renewal
major incident recovery
legal work, including advice on disputes
A real quote should say which of these are covered elsewhere. That way nothing gets counted twice. A lower transfer fee doesn't prove a lower whole year cost or a better result.
For the wider budget, see ongoing support scope and cost and the full website cost and licence budget. For separately scoped work, try estimating separately scoped website work.
Finish the handover and keep the record current
For an ordinary transfer, remove access nobody needs once the replacement access is accepted. Reduce any temporary permissions and confirm continuing support roles.
Review every access route, including machine ones:
Access route | Check |
|---|---|
Human users, shared logins and sessions | Remove or reduce them, and end active sessions |
Recovery routes | Recovery emails and phones point to the business |
Service accounts and API keys | Replace them before removing the old ones |
SSH and deploy keys | Remove keys the business doesn't control |
App grants and webhooks | Revoke old grants and check webhook destinations |
Scheduled tasks and backup access | Confirm who runs them and who can reach backups |
Replace or rotate secrets in a planned order so dependent services keep working. A password change alone isn't offboarding.
Coordinate Search Console token removal with the dependency checks above. Keep a record of what was removed and retested.
Agree with the former provider how they'll handle:
returning your data
remaining copies and exports
staging sites and backups
any legal, contractual or dispute reason to keep copies
APP 11 applies to organisations covered by the Privacy Act. It asks for reasonable steps to "destroy or de-identify" personal information no longer needed, subject to exceptions. It isn't an instruction to delete everything immediately.
Change billing and renewals only for the agreed services. Don't cancel a bundled subscription while it still supports email, DNS, backups or a licence. Keep the register and written operating notes where an authorised business backup contact can find them.
Accepted scope: [services, tasks and evidence]
Remaining issues: [owners, dates and approved exceptions]
Access: [removed, reduced, replaced and retained roles]
Automation: [keys, tokens, webhooks and schedules checked]
Data: [returned copies, retention basis and disposal plan]
Billing: [continuing subscriptions and authorised cancellations]
Support: [responsible team, escalation and renewal contacts]
Approval: [business approver, date and next review]
Retention and deletion depend on the actual information, rights and obligations. Don't apply a blanket rule to delete every historical record.
What we recommend at Elev8d
A good handover is a quiet one. Get control first, prove each piece works with evidence, and change one thing at a time. If you'd like help taking over a website, see our ongoing website development and support.
Frequently asked questions
Do we have to move the domain registrar?
No. A developer change doesn't require a registrar change. Move it only for a reason, using the provider's transfer process.
What happens to the agency's licences?
They may stay with the agency. Check each one and budget for replacements before the old subscription ends.
Do we need a new analytics property?
Usually not. Keep the existing property and fix the access. A new one splits your reporting.
When can we cancel the old hosting?
After acceptance, once the recovery plan no longer needs it. Check nothing bundled with it, like email or DNS, still depends on it.
Next steps
Pick the situation that fits.
Planning a handover
Build the register this week, starting with the domain and DNS.
Partway through a handover
Run the acceptance tests before anyone removes old access.
Locked out or in a dispute
Send a factual written request. Get advice on any contested rights.
Suspecting a compromise
Follow the incident route now. Don't wait for the routine checklist.
