You can normally change web designer without changing your domain or starting the business again online. A clean move begins by identifying who controls the domain, DNS, hosting, website files, databases, email, analytics, licences and third-party services before anyone changes anything.
Changing supplier should not be dramatic.
Sometimes it is.
Usually because the handover begins with:
We don't actually know where anything is.
The safest approach is to map the current setup first.
Then decide what needs transferring, rebuilding or simply leaving alone.
You do not normally need a new domain
This is important.
The domain belongs to the business identity, not the old design.
A new developer can build a new site and later point the existing domain toward it.
Customers can continue using the same address.
Search engines can continue seeing the established domain.
Business email can remain attached to the same domain.
That depends on the business having proper domain control.
Read who should control your domain if that part is unclear.
First: identify the registrar
Where is the domain registered?
Can the business access the account?
Who receives renewal emails?
Do not begin migration work without answering that.
For .ie domains, the registry WHOIS service can currently show the registrar and renewal information.
Other domain extensions have their own provider/registry mechanisms.
The point is simply to know who controls the address.
Then identify DNS
DNS may be managed at the registrar.
Cloudflare.
Hosting provider.
Another service.
This matters because DNS may control more than the website.
Business email may rely on MX records.
Verification records may exist for Microsoft 365, Google Workspace or other services.
Replacing the DNS zone blindly can break systems that were not being migrated.
A new developer should understand the current records before changing nameservers or website targets.
That is why DNS is such an important handover concept.
Identify the hosting or deployment platform
Where does the current site actually run?
Traditional web host?
WordPress host?
Wix?
Squarespace?
Shopify?
Cloudflare?
Something proprietary?
The migration plan depends on the answer.
A static site may be portable as source files.
A WordPress site may need files and database.
A hosted builder may have platform-specific export limitations.
Do not assume every website can be moved in exactly the same way.
Get a recoverable copy before major changes
If the current site matters, create a backup or recovery point before migration.
For WordPress, that usually means database and relevant files.
For static sites, make sure the source is safely stored.
If the current provider offers backups, understand what they contain.
This protects against the handover itself creating downtime.
Read how website backups work for the architecture differences.
Understand what source files exist
A finished live site is not always the same thing as the source project.
A developer may have design files.
Source code.
Build configuration.
CMS setup.
Licensed assets.
Ask what is available and what the contract says can be handed over.
That is where website ownership becomes practically important.
Do not wait until the final day to discover the site was built on a platform that cannot be exported in the way you assumed.
Preserve email
This deserves repeating.
The website can move without moving email.
If the business email works, avoid disturbing it unnecessarily.
Document the existing mail records.
If email itself is being migrated, treat that as a separate planned task.
Website launch day is already enough excitement.
Do not casually combine it with an unplanned email migration.
Preserve analytics and Search Console
If the business has Google Analytics and Google Search Console, keep access.
These accounts contain useful history.
A redesign does not require throwing that away.
The new developer may need access to implement tracking correctly and inspect existing search performance.
If a site already receives organic traffic, Search Console can also help identify pages that deserve careful migration.
Preserve useful URLs when redesigning
A change of designer sometimes becomes a full redesign.
If the old site has pages that already receive traffic or links, changing every URL without a plan can create unnecessary SEO damage.
Keep useful URLs where sensible.
Where URLs must change, use appropriate redirects.
Update internal links.
Keep canonical and sitemap configuration sensible.
A redesign is not an excuse to erase the site's search history.
This is one of the reasons migration requires more care than building a brand-new site on a brand-new domain.
Audit third-party services
Forms.
Booking.
Payment.
Newsletter.
CRM.
Review widgets.
Maps.
Chat.
Analytics.
Cookie/consent tools.
Identify which accounts exist and who controls them.
A new developer may not need to replace them.
If the current service already works and belongs to the client, preserving it can be simpler.
Changing everything at once creates risk without necessarily creating value.
Check paid licences
Fonts.
Plugins.
Themes.
Stock imagery.
Booking tools.
Premium software.
Some licences belong to the client.
Some may belong to the old agency.
Some may need replacing after the handover.
Clarify this before the old relationship ends.
A cheap migration can become more expensive when several hidden agency licences suddenly disappear.
Do I need the old designer's permission?
That depends on the contract, rights and accounts involved.
If the business controls the domain and owns or has the necessary rights to the website assets, changing supplier is usually a commercial/technical handover.
If there is a dispute over ownership, unpaid invoices, copyright or account access, legal issues may arise.
A new developer should not pretend to resolve those by technical force.
Get the rights clarified properly.
Gavin's take
Changing web designer should be an operational handover, not a hostage negotiation. Sometimes there are genuine contractual or licensing limits, but routine control of a business domain, access to agreed deliverables and a clear picture of recurring services should not become a surprise only when the client wants to leave. Lock-in is easiest to spot at the exit, which is why I prefer ownership and portability to be discussed at the start.
What if the old designer refuses to cooperate?
Separate what you control from what you do not.
Domain.
Registrar.
Hosting.
Backups.
Public content.
Third-party accounts.
Contracts.
If the provider has completely disappeared, recovery becomes the scenario covered in what happens if your web designer disappears.
If there is an active dispute, keep communications and records.
Do not risk the domain by making rushed changes.
What I'd do
Before deciding whether to rebuild anything, I would take a clean snapshot of the current setup: domain and DNS, hosting, source files, backups, analytics, Search Console, forms, email dependencies, paid licences and important URLs. Then I would assess the website on its own merits. A supplier change and a redesign are two separate decisions, and combining them automatically can create cost and risk the business did not need.
Moving designer does not always mean rebuilding the website
Perhaps you like the current site.
You only need somebody else to maintain it.
If the architecture is healthy and the rights/access are clear, a new provider may simply take over.
Likewise, an old website may need a rebuild.
The decision should be based on the site itself.
Not on the fact the supplier changed.
Use the website redesign guide to separate those questions.
How Built by Gavin approaches inherited sites
The first job is understanding what exists.
I would rather spend time mapping the setup than rush into changing it.
What works?
What should stay?
What does the client control?
What does email depend on?
What has search value?
What is genuinely obsolete?
Then we can decide whether the sensible answer is a takeover, partial improvement or clean rebuild.
The business should not pay to replace systems merely because I did not build them.
What should a good handover feel like?
Boring.
The old site remains live while the new arrangement is prepared.
Important accounts are transferred or shared.
Email keeps working.
The domain stays under control.
The replacement site is tested.
DNS changes are made deliberately.
Redirects are ready where required.
The customer sees the new site.
That is a successful migration.
Drama is not evidence of technical sophistication.
The bottom line
Changing web designer should not mean losing your domain, email, analytics or search history.
Map the current system first.
Secure access.
Back up what matters.
Clarify ownership/licences.
Preserve email.
Plan DNS.
Protect useful URLs.
Then move deliberately.
A website should be portable enough that changing supplier is a business decision, not a hostage negotiation.
Thinking about changing web designer?
I can help you identify what you already have, what is worth keeping and whether the sensible next step is a handover, improvement or rebuild. You can also see my work and current pricing.
---