Migration · Duda → WordPress
Duda is built for agencies shipping sites quickly, and it is good at that. What it does not do is hand the site back: the design lives in Duda’s editor, the pages live on Duda’s hosting, and leaving means rebuilding rather than downloading. We extract the content, rebuild the design as a real WordPress theme you own, and map every URL so the move costs nothing in search.
Why switch
Duda bills per site, every month, for as long as the site exists. On WordPress the software is free and hosting is a commodity you can shop for — the spend stops being a tenancy.
The layout lives inside Duda’s editor. There is no theme to hand to another developer, so changing supplier and changing platform end up being the same decision.
One site on a closed platform is a risk. Thirty client sites on one is a business dependency — pricing, feature decisions and renewal terms all set by someone else.
Structured data, integrations, custom post types, real plugins — each is available exactly to the degree Duda chooses to expose it, and not beyond.
What moves
Process
Every migration is a parallel build: your Duda site keeps running while the new WordPress site is built and verified beside it. The switch is a planned window, not a leap.
Questions
If your Duda to WordPress question is not covered here, send us the details and we will reply with a straight answer.
Not as a site. There is no archive you can download and run somewhere else — that is what a hosted platform means in practice. Content comes out by working through the live site; the design and layouts are rebuilt as a WordPress theme. It is the least elegant part of the job and it is entirely routine for us.
They become a proper content model. Collections are structured data driving pages, so in WordPress they map to custom post types with real fields rather than being flattened into a set of static pages. That keeps the useful part — add a row afterwards and the page still generates itself.
They can, and usually they should not all move at once. The first site is where the theme, the content model and the redirect pattern get decided; after that each further site is largely applying a known pattern, which costs a fraction of the first. We sequence them around your client commitments rather than ours.
Yes, with the same method as every migration we run: a full URL inventory taken before anything changes, one-to-one 301 redirects, metadata and structured data carried across, and Search Console watched for the weeks afterwards. Rankings follow content when the URLs are handled deliberately.
As close as you want it to. The design is rebuilt rather than exported, which means it can be reproduced faithfully or tidied up on the way through — a decision worth making deliberately, because the second option is cheaper and often better. Either way it ends up as a theme with patterns your team can use.
Two routes, and you do not have to choose straight away. The simpler one leaves the registration where it is and repoints DNS at the new host. The other transfers the registration to a registrar of your choosing, which needs the domain unlocked and an auth code, and which ICANN blocks for the first 60 days after any registration or transfer. Either way the existing MX records are carried across unchanged, so email keeps working through the switch.
