Some website migrations are really redesigns. Others are really data projects. This one was both.
When Steven Murphy Electrical Contractors approached Delicious Web Design, the job was not simply to give an ageing website a fresh coat of paint. Behind the existing site was a large Kentico 12 installation containing roughly 300 pages, years of content, media, URL history and search-engine value that could not simply be thrown away.
The challenge was clear: move the site to WordPress and Divi 5, modernise the experience, preserve the SEO foundations that had accumulated over years, and do it without putting the live Kentico website at risk.
The first rule: don't break the thing you're replacing
Before we designed a page or imported a file, we established a rule that governed the entire migration: the live Kentico website was read-only.
No experimental saves. No publishing. No reorganising content. No deleting old records. No changing configuration to make extraction easier. Discovery on the production system had to be non-destructive, with the actual build and import work happening away from the live site.
That sounds obvious until you are faced with a legacy CMS and need to understand how hundreds of documents, custom fields, aliases, media items and attachments relate to one another. The temptation is always to “just change this one thing” to make the next step easier. We deliberately refused to do that.
Instead, we treated the existing website as evidence. We inspected it, mapped it, exported from it and left it alone.
A 300-page website is not 300 pages
One of the first lessons in a migration of this scale is that the visible page count tells only part of the story. A page may have its main body stored in one place, additional content in custom fields, images in a media library, downloadable files as attachments, and historical or alternate URLs stored separately again.
Our Kentico access also imposed practical limits. SQL Console results were restricted to 100 rows, so there was no magic “export the whole website” button waiting for us. The extraction had to be broken into controlled, repeatable stages.
We progressively built a frozen migration dataset covering the site's document structure, custom content, URL aliases, media library and attachments. That eventually gave us the source material we needed without requiring the new WordPress site to connect back to the live Kentico database.
So we built the migration tool we needed
Rather than manually copy hundreds of pages and hope nothing was missed, we built a purpose-specific WordPress migration plugin for the project: SMEC Kentico Migrator.
Its job was not to be clever for the sake of being clever. Its job was to make the migration repeatable, auditable and safe.
The plugin worked from the frozen exports and publicly accessible source media rather than connecting to the production CMS. As we learned more about the Kentico structure, the importer grew in stages. Document hierarchy came first. Then custom content had to be joined to the correct documents. Media needed its own import path. Attachments needed another. URL aliases had to be preserved. Internal Kentico-style references had to be recognised and translated into their new WordPress equivalents.
Each stage existed because we had found a real relationship in the source data that needed to survive the move. We did not try to predict the entire migration architecture on day one. We inspected, proved, added the smallest required capability, tested it, and then moved to the next layer.
Preserving years of SEO work
A redesign can look spectacular and still be a disastrous migration if Google suddenly discovers that years of established URLs have disappeared.
For SMEC, preserving search value was a core engineering requirement, not something to think about after launch. Existing page titles, slugs, hierarchy, headings, metadata and useful URLs had to be respected. Where old aliases existed, they had to be accounted for. Internal links that still used Kentico's ~/ notation or pointed to the old domain needed to resolve correctly on the WordPress site.
By the time the migration importer reached its mature checkpoint, it had imported 198 documents with no missing documents, joined the available custom content, migrated 363 media items and 41 attachments, and preserved 62 unique aliases without conflicts. The integrity audit also confirmed that 1,841 Kentico-style internal references and 358 old-domain URLs had been resolved.
Those numbers matter because they represent something more useful than “the importer ran successfully”. They gave us measurable evidence that the relationships inside the old site had survived the journey.
Migration first. Redesign second.
There was another important decision: the new website was never intended to be a carbon copy of the Kentico site.
Once the content foundation was safely in WordPress, we could treat the project as a genuine redesign. Divi 5 gave us a modern visual system, while custom development handled the pieces that needed to behave differently from ordinary page content.
The new site uses the established Steven Murphy Electrical Contractors branding, but presents it with a much stronger visual hierarchy, clearer service navigation and a more contemporary editorial style. Large service areas could be rebuilt around reusable templates rather than hundreds of isolated layouts.
We also developed continuous service conveyors, responsive location content, a latest-news carousel, custom enquiry behaviour and a new form architecture designed around something the old system had made especially important: enquiries must not disappear simply because an email fails.
The enquiry system became part of the migration story
The legacy website had its own operational history, including contact identifiers and email delivery requirements. Rather than recreate that loosely, the replacement architecture was designed around a database-first principle.
A successful enquiry is saved first. A sequential Contact ID is allocated. Only then are notification emails sent. Delivery status can be recorded independently, so an SMTP problem cannot turn a legitimate customer enquiry into lost data.
The same system can record the form used, the exact page the enquiry came from, campaign attribution and delivery status. For a service business, that is far more useful than a contact form that simply fires an email into the darkness and hopes for the best.
Why this project looked impossible at first
There was no single dramatic technical trick that made this migration work.
It worked because the problem was broken down into things we could prove.
We proved what was in Kentico before trying to recreate it. We froze the source data before building against it. We kept the live CMS read-only. We added migration capabilities only when the source evidence justified them. We checked document counts, joins, media, attachments, aliases and internal references rather than assuming an import was complete because the screen said “success”.
And only once the content foundation was under control did we let the redesign become the star of the show.
The goal was never simply to move 300 pages. It was to move the history, structure and search value behind those pages, then give the business a website that felt new.
The result
What began as a daunting legacy-CMS migration became a controlled WordPress rebuild with a verified content pipeline behind it. The old Kentico installation could remain untouched while the new site was assembled, tested and refined independently.
For us as designers and developers, that is the part of projects like this that rarely fits into a portfolio screenshot. The finished homepage is the easy thing to show. The real work is everything underneath it: understanding an unfamiliar system, protecting what already has value, building the tools that do not yet exist, and knowing when not to touch something.
Sometimes good web design is typography, spacing and imagery.
Sometimes it is writing a migration plugin, reconciling hundreds of records and refusing to press Save on the wrong server.
This project needed both.
