Website migration without losing enquiries is the job
Moving a website to a new host or launching a rebuild is usually sold as the big scary bit. In practice, the homepage coming across is the easy part. The awkward stuff lives around it: DNS, SMTP, contact forms, redirects, webhooks, tracking scripts and the old inbox nobody admits is still in use.

A website migration without losing enquiries means testing every route a lead can take before and after launch. That includes forms, phone links, WhatsApp links, email delivery, booking widgets, CRM webhooks, redirects from old URLs, analytics events and rollback options. A migration is complete when the business process still works, not when the new pages merely load in a browser.
The false assumption: copied pages mean a successful migration
Not ideal.
A lot of migration plans focus on files, database, theme, plugins and whether the site looks right on the new server. Those things matter, obviously. But they do not prove that enquiries are still reaching the business.
The new host might serve the website perfectly while password resets stop sending, contact emails disappear, the CRM integration fails quietly, and the Google Ads landing page returns a 404. The website is live, everyone relaxes, and the enquiry pipeline has a hole in it.
That is usually where the fun starts.
Stage 1: map every lead route before touching DNS
Before changing nameservers or pointing the domain at a new server, list every way a visitor can become an enquiry. Do not just test the main contact form. That is the one everyone remembers.
- Contact forms on main pages, service pages and landing pages
- Newsletter signups, quote forms, booking forms and callback forms
- WhatsApp, phone and email links, especially on mobile
- CRM webhooks, Zapier routes and email marketing integrations
- WooCommerce account emails, password resets and order notifications if relevant
- Old campaign URLs, referral links and QR code destinations
- Thank-you pages, conversion events and analytics tracking
One boring detail that catches people out: the form success message does not prove delivery. A form can say thanks and send nothing. It is just being polite about failing.
Stage 2: build a pre-launch enquiry-path test matrix
The test matrix does not need to be fancy. It needs to be specific enough that somebody can repeat it and compare the result after launch.
| Route | Pre-launch test | Expected result | Priority |
|---|---|---|---|
| Main contact form | Submit from staging or hosts-file preview | Email arrives in correct inbox and CRM records lead | High |
| Password reset | Request reset for a test user | Reset email arrives and link works | High |
| WhatsApp link | Tap from mobile header and footer | Opens correct UAE or UK number | High |
| Old service URL | Visit old live URL on preview rules | Redirects to correct new page, not the homepage | High |
| Analytics conversion | Complete a test enquiry | Event records in the correct property | Medium |
This is the kind of practical launch discipline we use in WordPress development work for service businesses, especially when a website needs to carry enquiries rather than just sit there looking expensive. If you are planning a rebuild or migration in the UAE, the website development Dubai service is the natural place to start.
Stage 3: check DNS and email as separate jobs
DNS is not one switch. There may be A records, CNAME records, MX records, TXT records, SPF, DKIM, DMARC, subdomains and third-party services involved. If someone moves hosting and accidentally changes email records, the website might load while business email starts wobbling.
Keep a record of the current DNS zone before changing anything. Screenshot it, export it, copy it into a document, whatever works. Then confirm what is actually moving. Hosting can move without email moving. Email can stay with Microsoft 365, Google Workspace or another provider.
SMTP settings also need checking. A new server may block certain mail functions or expose an old form plugin that was relying on default PHP mail. That is not a migration success. That is a hidden delivery problem with a nice new coat of paint.
Stage 4: redirects are part of the lead path
Redirects are not only an SEO issue. They are also an enquiry issue.
If an old service page has backlinks, saved bookmarks, sales team email signatures or paid campaign history, it should land somewhere sensible after launch. Dumping everything onto the homepage is lazy and often confusing for the visitor.
Build redirects from old high-value URLs to the most relevant new URLs. Test them before launch where possible, then crawl them after launch. Pay special attention to Dubai, UAE, UK or Liverpool location pages if they bring in qualified enquiries.
Stage 5: set a rollback point before launch
Migration plans need a way back. Not because you expect everything to fail, but because panic fixes make a mess.
Before launch, confirm:
- There is a recent backup of the old site and database
- The old hosting account will not be cancelled immediately
- DNS TTL is lowered in advance where appropriate
- Someone knows who can reverse the DNS change
- The launch is not happening five minutes before everyone goes home
Proper rollback planning is dull. So is having a fire extinguisher. Still worth having.
Stage 6: post-launch tests before celebrating
Once DNS has changed and the new site is resolving for real users, run the same enquiry-path matrix again. Use different devices and networks where possible. A mobile-only sticky button going to the wrong WhatsApp number is exactly the sort of daft detail that costs enquiries.
Check spam folders too. Check the old inbox. Check the CRM. Check whether analytics is receiving the event. Check whether the thank-you page is indexable if it should not be. None of this is glamorous. It is the job.
When migration becomes repair work
If the migration has already happened and enquiries have gone quiet, stop changing things until you know what changed first. Look at DNS history, form logs, SMTP configuration, plugin changes, server error logs and redirect rules.
The plugin might be guilty. It might also just be standing closest to the scene of the crime.
For broken forms, lost email delivery, redirect damage or post-launch issues after a move, website repair Dubai support can help identify what failed without turning the live site into a guessing game.
A sensible launch order
- Audit current website, forms, DNS, email and integrations.
- Build or move the website in a controlled staging or preview environment.
- Create the enquiry-path test matrix.
- Test forms, SMTP, webhooks, redirects, mobile CTAs and analytics before launch.
- Prepare backups, DNS records and rollback access.
- Change DNS only when the business process has been tested.
- Repeat the same tests after launch and monitor enquiries.
The smallest sensible next action is simple: write down every enquiry route your website currently has. If you cannot list them, you are not ready to migrate. Harsh, but fair.
FAQs about website migration without losing enquiries
Can I migrate a WordPress website without downtime?
You can reduce downtime risk with good preparation, preview testing, DNS planning and a rollback point, but nobody sensible should guarantee zero downtime for every setup. Hosting, DNS propagation, third-party tools and email services all affect the launch. The practical aim is controlled change, quick verification and a clear way back if something breaks.
Why did my website form stop working after a hosting migration?
Common causes include SMTP settings not being carried over, server mail restrictions, missing DNS records, a form plugin configuration issue or a failed CRM webhook. The form may still show a success message even if no email arrives. Test delivery to the inbox and CRM, not just the front-end message.
Do I need to move email when moving website hosting in Dubai or the UAE?
Not always. Website hosting and email hosting can be separate. Many businesses keep email on Microsoft 365, Google Workspace or another mail provider while moving the website server. The risky bit is changing DNS without preserving MX, SPF, DKIM and DMARC records. Record the current setup before changing anything.
What redirects should be tested during a website migration?
Test old service pages, landing pages, campaign URLs, high-traffic blog posts, location pages and any URLs used in ads, emails, QR codes or sales documents. Redirect each important old URL to the closest relevant new page. Sending everything to the homepage is usually poor for users and weak for lead quality.
Should analytics be part of a website migration checklist?
Yes. Analytics does not create enquiries, but it helps you see whether key routes are still being used and measured. Check tracking scripts, consent tools, conversion events, thank-you pages and form submission events after launch. Otherwise the business may be getting leads but losing visibility, or losing leads without spotting it quickly.
Test every lead route before changing DNS. If you want a practical second pair of eyes on the migration plan, message Standish Services on WhatsApp before the switch is made.