From Enquiry to Live Website in Five Hours

A WordPress migration that started at 2pm

Evan Quigley Electrical contacted me at around 2pm needing help moving an existing WordPress website away from its previous provider.

By around 7pm that evening the website was running from my hosting, the required DNS changes had been completed and the live domain was pointing at the new server.

DNS propagation was unusually cooperative, which certainly helped, but there was still more involved than simply copying a website from one server to another.

The domain also supported the company's existing email services, so the migration needed to be carried out without unnecessarily changing mail-related DNS records or disrupting systems that were already working.

Working with the handover that was available

The previous provider supplied an All-in-One WP Migration .wpress file rather than what I would normally regard as a complete hosting handover.

A .wpress file is perfectly usable if you know which software produced it and how to restore it. I already use All-in-One WP Migration, so in this case there was no reason to turn a manageable situation into a more complicated one.

I created a clean WordPress installation on my server, restored the supplied export, checked that the site had transferred correctly and then prepared it for the domain cutover.

A less familiar migration format could easily have slowed the process down considerably, especially when there was no traditional hosting backup or full migration package available.

The migration was only the first part of the job

Once a site has successfully moved, I do not assume that everything inside it has been configured correctly simply because the pages load.

I went through the inherited WordPress installation in more detail and found a mixture of current functionality, old settings and technical remnants from the way the replacement website had originally been developed.

Nothing suggested the site needed to be thrown away. It did, however, need some proper housekeeping.

• Main page URLs still carried unnecessary -1 suffixes
• Yoast SEO had not been fully configured
• XML sitemaps were disabled
• Relevant Yoast schema functionality had not been enabled
• The site's llms.txt functionality was disabled
• Multiple SMTP plugins were installed
• The active SMTP configuration was failing
• WordPress still contained administrator details from the previous setup
• Wordfence alerts were still being sent to an old developer email address
• The custom solar form used the generic WordPress administrator address for lead notifications
• Several form plugins appeared to be remnants of previous website versions

Cleaning up the page URLs properly

A number of the main pages had URLs ending in -1.

That usually happens when replacement pages are created directly inside an existing live WordPress installation while the original pages still occupy the preferred URLs.

WordPress therefore creates a variation of the slug rather than allowing two pages to use the same address.

It works, but I would not normally regard URLs such as /contact-us-1/ as a finished production structure when /contact-us/ is available and preferable.

I updated the affected pages to use cleaner URLs and added redirects from the previous addresses.

That last part matters. Renaming an existing page without redirecting the old URL can result in broken external links, unnecessary 404 errors and lost search equity.

Fixing email delivery rather than assuming the forms worked

The website had both FluentSMTP and WP Mail SMTP installed.

FluentSMTP was effectively controlling WordPress mail, but the outgoing SMTP connection it had been configured to use was failing.

Installing multiple SMTP plugins does not provide useful redundancy. It can instead make it less obvious which system is actually handling WordPress mail and makes troubleshooting harder than necessary.

I moved outgoing WordPress mail onto my established SMTP2Go configuration, successfully tested delivery and removed the competing SMTP plugins from the active setup.

I also found that the WordPress administration email was still associated with the previous setup, while Wordfence security alerts were going to an old Gmail address belonging to the former provider.

Those destinations were corrected as part of the takeover.

This is why testing a website form means more than checking that the form appears on the page. The visible form, its notification settings and the server's ability to deliver the resulting email are separate parts of the process.

Understanding what was actually handling the website forms

The WordPress installation contained Elementor Pro, Fluent Forms, Gravity Forms and a separate bespoke solar enquiry plugin.

Simply seeing several form plugins in WordPress does not tell you which one is actually in use.

Reviewing the live page markup established that the main Contact page was using an Elementor Pro form, while the solar enquiry process was being generated separately by a custom plugin.

The custom solar form

The solar form sends one notification internally and a separate confirmation email to the customer.

The internal lead notification had been coded to send to WordPress' generic administrator email address.

I amended that single recipient so solar enquiries now go directly to info@evanquigleyelectrical.co.uk, while WordPress system notifications remain separate.

Connecting the website with Tradify

Evan Quigley Electrical then asked whether its general website enquiries could feed directly into Tradify, which is already used by the business to manage incoming work.

Tradify provides a TradeHQ enquiry form that supports embedded use, so I integrated that directly into the website Contact page.

Customers can now submit their contact details, job address, description and attachments through the website, while the enquiry enters the company's existing Tradify workflow.

That is a much more useful outcome than generating another standalone email that somebody subsequently has to transfer into the system manually.

Finishing the SEO and search setup

Yoast SEO was already installed, but installing an SEO plugin and configuring one properly are not necessarily the same thing.

I reviewed the setup, enabled XML sitemaps and the relevant schema functionality, checked the site's metadata and made sure the technical SEO foundations were operating as expected.

I also established proper ownership of the site in Google Search Console.

I only have delegated access to the client's GoDaddy domain, so Google's automatic GoDaddy verification route could not confirm my account.

Instead, I verified ownership manually through DNS. That gives the website a properly verified Search Console property without depending on the previous provider's access.

The existing Google Analytics implementation also needed to be traced. It was not being added through a conventional analytics plugin, but through Elementor's Custom Code area.

Finding an existing implementation before adding another one matters. Adding a second tracking script without understanding what is already running can result in duplicate analytics data and a much less useful reporting setup.

A new-looking website can still contain old WordPress baggage

Fluent Forms and Gravity Forms both still contain forms inside the WordPress dashboard, although the current public-facing enquiry routes appear to use Elementor Pro, Tradify and the bespoke solar form instead.

That suggests at least some of the forms and plugins may have belonged to an earlier version of the website and were simply carried forward when the newer site was built.

I do not delete something purely because it looks redundant.

Before removing a plugin from an inherited site I would normally establish whether its shortcodes, widgets, stored submissions or other functionality are still being referenced anywhere.

The sensible approach is to verify, deactivate, test and only then remove it permanently.

This kind of housekeeping is rarely visible to a website visitor, but reducing unnecessary plugins makes an installation easier to understand, maintain and support.

The value was not in any one individual setting

There is an important distinction between a technically difficult task and a technically responsible one.

Changing a DNS record is straightforward.

Editing a form recipient is straightforward.

Enabling an XML sitemap is straightforward.

The value comes from knowing which DNS records should not be changed because they support the client's email, identifying which plugin has taken control of WordPress mail, recognising that a form is custom coded rather than managed by one of the visible form plugins, preserving existing URLs through redirects and separating operational enquiries from system notifications.

It also means doing those things on a live business website without creating a new problem while fixing the existing one.

A good website takeover is part migration, part investigation and part risk management.

In this case, the first visible result was a website moved from one provider to another in around five hours.

The more useful long-term result is that Evan Quigley Electrical now has a website whose hosting, DNS, forms, email delivery, enquiry routing, Search Console access and core SEO configuration are understood and supportable.

What happens next?

The existing website does not need to be replaced simply because there are things I would have approached differently when building it.

It now has a cleaner technical foundation, which means any future investment can concentrate on improving what the website actually does for the business.

That could include stronger dedicated service pages, improved local search targeting, useful advice content, better internal linking and turning selected completed projects into proper case studies.

Regular useful content is another opportunity.

Businesses do not necessarily need to write all of this themselves. I can research, write, optimise and publish website articles around the services customers are genuinely searching for.

This is an approach I already use with clients such as AR Windows, where building out useful specialist content over time has contributed to increasing search visibility, online presence and website enquiries.

It is not a quick SEO trick. It is about steadily making a business website a better and more authoritative resource.

Final thoughts

Taking over an existing WordPress website is rarely just a hosting job.

You inherit the decisions, plugins, shortcuts, integrations and configuration left by everybody who has previously worked on it.

Sometimes that is all beautifully documented and straightforward.

Sometimes it takes a little investigation.

My preference is to understand what is already there before recommending major changes, fix the things that genuinely need attention and then give the client sensible options for improving the website over time.

If you have inherited a WordPress site, need to move away from an existing provider or simply want somebody to work out what is actually going on behind the scenes, you can find out more about my WordPress website services or get in touch.

Frequently asked questions