Custom WordPress Theme Migration: The Complete 2026 Guide

If you are running a custom WooCommerce theme and someone tells you migration is a copy-paste job, walk away. A botched custom WordPress theme migration can knock a live store offline for 6 to 12 hours, silently break checkout, and quietly delete the exact template overrides that make your storefront yours. We have watched teams lose an entire quarter of SEO equity because a migration flattened their custom permalinks and 404’d 4,000 indexed URLs.

The good news: a custom theme is not a blocker. It is a variable you plan around. Done properly, you can move a heavily customized WooCommerce build to new hosting, a new domain, or a fresh staging-to-production pipeline with effectively zero data loss and under 60 seconds of real downtime. This guide is the exact sequence our team uses when we scope this for clients, in strict implementation order.

TL;DR

• Custom themes migrate fine, child themes migrate best: A properly structured child theme with isolated template overrides moves cleanly in 90% of cases. The 10% that break are almost always theme-embedded plugins, hardcoded absolute URLs, or license-locked parent themes that refuse to reactivate on the new environment.
• The order of operations decides your downtime: Migrate to a staging environment first, validate WooCommerce checkout and custom templates in full, then cut over DNS last. Teams that flip production directly average 4 to 8 hours of downtime; teams that stage-and-cut average under 2 minutes.
• Your custom files live in three places, and you must account for all three: The child theme directory, the database (widgets, customizer settings, WooCommerce settings), and the uploads folder. Miss any one and the site looks broken even when the migration technically succeeded.

Step 1: Audit exactly what “custom” means in your build

Before you touch a single file, you need an honest inventory. “Custom theme” means something different for every store, and the differences dictate the entire migration plan. When we scope a custom WordPress theme migration for a client, the first 3 to 5 hours are pure discovery, because a wrong assumption here is what turns a clean cutover into a 2-day firefight.

Is it a custom theme, a child theme, or a customized premium theme?

These three are not the same thing, and they carry very different migration risk.

Build type	What it actually is	Migration risk	Typical fix time if it breaks
True custom theme	Bespoke theme coded from scratch or from a starter like Underscores	Low to medium: everything is in the theme folder and version-controlled	1 to 2 hours
Child theme over a premium parent	Overrides layered on top of Astra, Flatsome, Divi, etc.	Medium: parent theme license reactivation is the common failure	2 to 4 hours
Directly edited premium theme	Someone edited the parent theme files in place	High: changes are undocumented and get wiped on any parent update	4 to 12 hours

That last row is the one that keeps store owners up at night. If your developer edited the parent theme directly instead of using a child theme, your customizations are not just fragile during migration; they are fragile every single time the theme author ships an update. At Presta, we have seen stores lose their entire product page layout because a routine parent-theme update overwrote in-place edits that were never in a child theme to begin with.

Where do your custom template overrides live?

WooCommerce lets you override its templates by copying them into your theme under a `woocommerce/` directory. This is standard practice, but it means a chunk of your storefront logic is sitting inside your theme folder rather than in the plugin. During a custom WordPress theme migration, these files must move byte-for-byte. Run a quick inventory:

1. Check `wp-content/themes/your-theme/woocommerce/` for overridden templates (cart, checkout, single-product, archive).
2. Check your `functions.php` for hooks that modify WooCommerce behavior.
3. Check for any custom post types or taxonomies registered in the theme rather than a plugin.
4. Note any hardcoded absolute URLs (a top cause of broken images and mixed-content warnings post-migration).

Pro Tip: Custom post types registered inside a theme’s `functions.php` are a hidden landmine. If you ever switch themes later, those post types vanish from the admin even though the data still sits in the database. During a migration this usually survives because the theme comes with you, but flag it now, because it tells you the build has architectural debt you may want to refactor into a plugin on the new environment.

Checklist for a complete build audit:

• Theme structure: Confirm whether you have a child theme, a true custom theme, or in-place parent edits.
• Template overrides: Catalog every file in the theme’s `woocommerce/` override directory.
• Functional code: Note custom post types, taxonomies, shortcodes, and hooks in `functions.php`.
• Parent dependencies: Record the exact parent theme name, version, and license status.
• Hardcoded URLs: Search theme files for absolute references to the current domain.
• Version control status: Determine whether the theme is in Git or exists only on the live server.

Checkpoint: You know exactly which of the three build types you have and can name every file and database setting that carries a customization. If you cannot, you are not ready for Step 2.

Step 2: Take a full, verified backup and set up version control

A backup you have not restored is a hope, not a backup. This step is non-negotiable, and it is where careless teams cut corners to save 30 minutes and end up losing 3 days.

What actually needs backing up?

A WooCommerce site with a custom theme has four assets, and a real backup captures all four:

Asset	What it contains	Backup method	Skip it and you lose
Database	Orders, customers, products, settings, customizer options	`mysqldump` or plugin export	Everything transactional
`wp-content/themes/`	Your custom theme and any parent	File copy / Git	Your entire design layer
`wp-content/uploads/`	Product images, media, invoices	File copy / rsync	Every image on the site
`wp-content/plugins/`	WooCommerce, gateways, extensions	File copy	Payment and shipping logic

Do not rely on a single “migration plugin” export as your only backup. Those bundles are convenient, but if the export corrupts mid-process, you have nothing. Our team always takes an independent database dump and a separate file archive before any migration tool touches the site.

How do you preserve custom theme files during migration?

This is one of the seed questions we get most often, and the answer is boring in the best way: put the theme in Git before you migrate anything. If your custom theme is not already version-controlled, this is the moment to fix it.

1. Initialize a Git repository inside your theme directory.
2. Commit the current live state as your baseline.
3. Push to a private remote (GitHub, GitLab, Bitbucket).
4. On the new environment, clone or deploy from that repository rather than FTP-dragging files around.

This gives you a byte-perfect record of your theme, an audit trail of any changes made during the migration, and an instant rollback path. When we build and hand off custom themes, they ship in Git as a matter of course, because a system that debugs cleanly starts with a system you can diff. If you want the reasoning behind that discipline, our own writeup on a systematic approach to debugging covers why reproducibility beats guesswork every time.

Pro Tip: Before you migrate, do a test restore of your database dump into a local or throwaway environment. A backup that restores cleanly in 5 minutes is worth ten backups you have never verified. We have seen “successful” exports fail on restore because the source server truncated large `wp_options` rows containing serialized customizer data, and nobody noticed until go-live.

Checklist for a migration-ready backup:

• Database dump: A standalone SQL export separate from any migration plugin.
• File archive: Themes, plugins, and uploads captured independently.
• Version control: Custom theme committed and pushed to a private remote.
• Restore test: Database dump restored successfully into a scratch environment.
• Config record: `wp-config.php` values noted (DB prefix, salts, constants).
• Offsite copy: At least one backup stored somewhere other than the source server.

Checkpoint: You have restored your database backup at least once into a non-production environment and confirmed your theme lives in a Git repository you can redeploy from. Only now are you allowed to migrate.

Step 3: Build a staging environment that mirrors production

Never migrate straight into production. Every clean custom WordPress theme migration we run goes through a staging environment first, because staging is where you discover the five things you forgot before your customers do.

Match the new environment to the old one

Custom themes often depend on the server environment more than owners realize. A theme built and tested on PHP 7.4 can throw fatal errors on PHP 8.2 because a deprecated function got removed. Before you move anything, align these:

Environment variable	Why it matters for custom themes	How to check
PHP version	Custom code may use deprecated syntax	`phpinfo()` on both servers
WordPress version	Template functions change between majors	Dashboard > Updates
WooCommerce version	Template override structure evolves	Plugins screen
MySQL/MariaDB version	Affects large query performance	Hosting panel
Memory limit	Complex themes need headroom	`wp_get_memory_limit()`
PHP extensions	Image processing, GD/Imagick	`phpinfo()`

Our rule of thumb: match the source versions exactly on staging first, get a fully working migration, and only then upgrade PHP or WooCommerce as a separate, controlled step. Bundling a version upgrade into the migration itself is how you end up unable to tell whether a bug came from the move or the upgrade.

Migrate files and database into staging

With a mirrored environment ready, the mechanical migration is straightforward:

1. Deploy your theme from Git into `wp-content/themes/`.
2. Upload the `uploads/` folder via rsync or SFTP (this is usually the slowest part; a 20GB media library can take 30 to 90 minutes).
3. Copy plugins across.
4. Import the database dump.
5. Update `wp-config.php` with the new database credentials and set staging-specific constants.
6. Run a search-and-replace on the database to swap the old domain for the staging domain, using a serialization-safe tool like WP-CLI’s `search-replace` (never a raw SQL `UPDATE`, which corrupts serialized data).

That serialization-safe search-and-replace is the single most common place a custom WordPress theme migration goes wrong. Customizer settings, widget configs, and many theme options are stored as serialized PHP arrays in `wp_options`. A naive find-and-replace changes the string length inside those arrays without updating the length prefix, and the whole option silently fails to unserialize. Your customizer settings vanish, and the site loads with default styling. Always use a tool that understands serialization.

Checklist for a faithful staging build:

• Environment parity: PHP, WordPress, WooCommerce, and MySQL versions matched to production.
• Theme deployed: Custom theme pulled from Git, not dragged over FTP.
• Media migrated: Full `uploads/` directory transferred and verified by count.
• Serialization-safe replace: Domain swap done with WP-CLI or equivalent.
• Search engine block: Staging set to discourage indexing so Google never sees the clone.
• Access lock: Staging protected behind HTTP auth or IP allowlist.

Checkpoint: Your staging site loads with your custom theme’s real styling, not the default fallback, and the homepage renders exactly like production. If it looks like a naked WordPress install, your serialized options did not survive the search-and-replace.

Step 4: Validate the custom theme and WooCommerce end to end

Staging is up. Now you test the parts that actually make you money. This is where a store migration differs sharply from a brochure-site migration: you have a transactional funnel that has to work perfectly, and a custom theme means custom risk in every step of that funnel.

What happens to your custom theme when you migrate?

Another seed question worth answering head-on: if you did Steps 1 through 3 correctly, the answer is “nothing bad happens to it.” Your template overrides, your `functions.php` logic, your customizer settings, and your styling all move intact. The theme behaves identically because it is the same code running against the same database on a matched environment.

The failures people attribute to “the theme broke during migration” are almost never the theme itself. They are:

• Serialized options not surviving a bad search-and-replace (Step 3).
• A license-locked parent theme refusing to activate on the new domain.
• Hardcoded absolute URLs pointing at the old server.
• A PHP version mismatch throwing fatals on deprecated theme code.
• File permission differences causing image upload directories to fail.

Run the full commerce validation pass

We validate every migration against a fixed checklist, because “the homepage looks fine” tells you nothing about whether someone can actually buy something. Here is the sequence our team runs:

1. Homepage and key landing pages render with correct styling and images.
2. Shop archive and category pages display products with correct pricing.
3. Single product page loads, including custom template overrides and variations.
4. Add-to-cart works and the cart updates without a full page reload if your theme uses AJAX.
5. Checkout page loads, applies taxes and shipping correctly, and shows clear error states.
6. A full test transaction completes end to end in the payment gateway’s test mode.
7. Order confirmation email fires and the order appears in the admin.
8. Customer account pages, order history, and downloadable products work.

This end-to-end discipline is exactly what we mean when we talk about instrumenting every step of a conversion flow. When we built our custom hotel booking engine as a Presta product initiative, the whole design principle was to separate the frontend from the PMS business logic, integrate at the API level, and keep the interface fully branded with a clear step-by-step flow, instant feedback, and explicit error states. That same philosophy, decouple the presentation layer from the transactional logic and validate each step independently, is why a well-structured custom WooCommerce theme migrates cleanly: the theme is the presentation layer, WooCommerce is the logic, and testing them as distinct layers is what catches problems before customers do. The booking engine let that client run multiple locations from one custom-made engine, saving cost and time, precisely because the presentation and logic were cleanly separated and reusable.

A custom theme does not make migration risky; skipping the end-to-end checkout test does.

Checklist for commerce validation:

• Styling intact: Custom theme renders identically to production, not a default fallback.
• Template overrides live: WooCommerce template customizations display correctly.
• Cart behavior: Add-to-cart and AJAX cart updates function.
• Test transaction: A full checkout completes in gateway test mode.
• Emails firing: Order confirmation and admin notification emails send.
• Account area: Login, order history, and downloads all work.
• Mixed content clean: No HTTP assets loading over HTTPS.

Checkpoint: You have personally completed a test purchase from product page to confirmation email on staging. Not “it should work.” You did it.

Ready to migrate without gambling your revenue?

A custom WooCommerce migration is not the place to learn on the job. Our Startup Studio team migrates and rebuilds custom WordPress and WooCommerce stores with zero-loss cutovers, serialization-safe database moves, and a full commerce validation pass before a single customer sees the new site. If your store does meaningful revenue and downtime costs you real money, talk to Presta’s Startup Studio and we will scope a migration plan that treats your custom theme as an asset to protect, not a risk to work around. You can also get in touch directly if you want a second set of eyes on a migration you are already mid-way through.

Step 5: Handle SEO, redirects, and URL integrity

If you are moving domains or changing your URL structure, this step protects the SEO equity you have spent years building. Get it wrong and you can lose 20 to 40% of organic traffic in the first month, sometimes more. Get it right and you carry your rankings across intact.

Preserve permalink structure and internal links

Your custom theme may generate internal links in template files. During the search-and-replace in Step 3, those should have updated, but verify it. Then:

1. Confirm permalink settings in the new environment match the old exactly (Settings > Permalinks).
2. Flush rewrite rules by re-saving the permalink settings.
3. Crawl the staging site with a tool like Screaming Frog and compare the URL list against a pre-migration crawl of production.
4. Every URL that changed needs a 301 redirect from old to new.

Build the redirect map before cutover

If your URLs are changing at all (new domain, HTTPS switch, restructured slugs), a redirect map is mandatory. This is not optional cleanup you do later; it goes live at the same moment as the site.

Change type	Redirect needed	Priority	SEO risk if skipped
Domain change	301 old domain to new, page by page	Critical	Total ranking loss
HTTP to HTTPS	301 all HTTP to HTTPS	Critical	Duplicate content, mixed signals
Slug/structure change	301 old slug to new	High	Lost rankings on changed pages
Trailing slash change	301 normalize	Medium	Duplicate URL indexing

Pro Tip: Export your top 200 URLs by organic traffic from Google Search Console before you migrate, and treat that list as your redirect priority tier. If everything else is delayed, those 200 URLs must have flawless 301s the moment the site goes live. In our experience, protecting the top 5% of URLs by traffic protects roughly 70 to 80% of the organic revenue at risk. This is the kind of prioritization that separates a smooth relaunch from a painful one, and we walk through the broader lifecycle in our journey of a new website writeup.

Checklist for SEO-safe migration:

• Permalink parity: Structure matches production and rewrite rules are flushed.
• Crawl comparison: Pre and post URL lists compared for any drift.
• Redirect map: Every changed URL has a 301, top-traffic URLs first.
• Canonical tags: Point to the new domain, not the old.
• XML sitemap: Regenerated and ready to submit to Search Console.
• robots.txt: Confirmed it does not block the new site (remove staging blocks).

Checkpoint: A crawl of staging returns zero unexpected 404s, and your redirect map covers 100% of your top-200 traffic URLs. Confirm before cutover, not after.

Step 6: Execute the cutover with minimal downtime

Everything so far has been preparation. The cutover itself, done right, is the shortest and least dramatic part of the whole process. This is the payoff for staging discipline.

The zero-drama cutover sequence

Here is the exact order we cut over a validated staging site to production:

1. Freeze content and orders on the old site (put it in maintenance mode or a brief order pause during a low-traffic window).
2. Take a final incremental database sync to capture any orders placed since the staging snapshot.
3. Run the final serialization-safe search-and-replace to swap the staging domain for the real production domain.
4. Lower the DNS TTL to 300 seconds a day in advance so propagation is fast.
5. Point DNS (or flip the load balancer / reverse proxy) to the new server.
6. Activate the redirect map.
7. Remove the search-engine-discourage flag so the new site can be indexed.
8. Submit the new XML sitemap to Google Search Console.

The reason this is fast is that the new site is already fully built, tested, and warm. You are not building anything at cutover; you are only redirecting traffic to a site that already works. This is how teams achieve sub-2-minute effective downtime on a migration that would otherwise take hours.

The Confident Cutover Framework

This is the strategic framework we hand clients so they know the state of the world at every phase:

1. Freeze: Stop new writes to the old environment so nothing is created that the new one will not have.
2. Sync: Capture the delta of orders and content created since the last staging snapshot.
3. Swap: Run the domain replace and point traffic at the validated new environment.
4. Verify: Run a live smoke test of checkout, forms, and top pages within the first 5 minutes.
5. Watch: Monitor error logs, analytics, and Search Console for 72 hours for anything that slipped through.

Following this five-phase framework, our migrations routinely land in the 1 to 2 minute effective-downtime range even for stores with tens of thousands of orders.

Checklist for the cutover:

• TTL lowered: DNS TTL reduced 24 hours ahead for fast propagation.
• Order freeze: Old site paused so no orders are lost in the gap.
• Delta sync: Latest orders captured before the final swap.
• Live smoke test: Checkout tested on production within 5 minutes of go-live.
• Redirects active: 301 map confirmed live on the production domain.
• Indexing enabled: Search-engine block removed and sitemap submitted.

Checkpoint: You have completed a real test purchase on the live production site and the order appears in the admin. The migration is not “done” until money can move on the live domain.

Step 7: Measure success with a 30/60/90 day plan

A migration is not finished at cutover. It is finished when your data confirms nothing regressed. We hold every custom WordPress theme migration to measurable outcomes across three windows, because “it feels fine” is not a metric.

What KPIs prove the migration worked?

Timeframe	What to check	Target outcome	Red flag
First 24 hours	Error logs, checkout completions, page load times	Zero fatal errors, conversion rate within 5% of baseline	Any drop over 15% in completed checkouts
30 days	Organic traffic, indexed pages, crawl errors in Search Console	Traffic within 10% of pre-migration, crawl errors trending down	Sustained 20%+ traffic loss, rising 404s
60 days	Rankings for top keywords, Core Web Vitals	Rankings stabilized or improved, CWV green	Rankings still sliding, LCP over 2.5s
90 days	Full organic recovery, revenue parity	Traffic and revenue at or above pre-migration levels	Revenue below baseline with no upward trend

A well-executed migration onto better hosting often improves things: we routinely see Core Web Vitals scores climb once a custom theme runs on properly configured infrastructure with object caching and a CDN, which can lift both rankings and conversion rate over the 60 to 90 day window.

Set up your monitoring before you need it

Instrument the analytics before cutover, not after. This is the same discipline that made our custom hotel booking engine work: every step of the funnel is measured, so you can see exactly where a conversion drops off. For a WooCommerce store, that means:

1. Confirm GA4 and Google Tag Manager are firing on the new environment, including enhanced ecommerce events.
2. Verify purchase events register with correct revenue values.
3. Set up uptime monitoring and error-log alerting.
4. Keep the pre-migration analytics data exported and accessible for comparison.

Checklist for measuring migration success:

• Baseline captured: Pre-migration traffic, conversion, and revenue numbers saved.
• Analytics verified: GA4 and GTM firing with correct ecommerce events.
• 24-hour watch: Error logs and checkout completions monitored live.
• 30-day review: Organic traffic and crawl errors compared to baseline.
• 60-day review: Rankings and Core Web Vitals assessed.
• 90-day close: Revenue parity confirmed and migration formally signed off.

Checkpoint: Thirty days post-migration, your organic traffic sits within 10% of baseline and your conversion rate is within 5%. If it is, the migration succeeded. If not, you have a specific number to investigate rather than a vague worry.

Common Mistakes

Mistake: Editing the parent theme directly instead of using a child theme. Why It Happens: A developer needs a quick change and edits the live parent theme file rather than setting up a child theme, saving 20 minutes now. Fix: Move all customizations into a properly structured child theme before migrating, so your changes are isolated, portable, and survive both the migration and future parent updates.

Mistake: Running a raw SQL find-and-replace to swap domains. Why It Happens: It feels faster than installing WP-CLI, and it works fine on plain text, so people assume it works everywhere. Fix: Always use a serialization-safe tool like WP-CLI’s `search-replace` so serialized customizer and widget data updates its length prefixes correctly and does not silently break.

Mistake: Cutting over to production without a staging validation pass. Why It Happens: Deadline pressure and overconfidence: the migration “should just work,” so teams skip the boring test phase. Fix: Always validate the full commerce funnel on a staging clone first, including a real test purchase, before pointing DNS at the new environment.

Advanced tips for complex custom theme migrations

Once you have the core sequence down, a few advanced practices separate a competent migration from a genuinely resilient one.

Refactor theme-embedded logic into plugins. If your custom theme has custom post types, shortcodes, or business logic baked into `functions.php`, a migration is the ideal moment to extract that into a small custom plugin. This decouples your data and logic from your presentation layer, which is the exact principle behind resilient architecture and something we lean on across our custom builds. The payoff: you can redesign or reskin the theme later without losing functionality.

Use a blue-green deployment for high-revenue stores. Instead of a hard DNS flip, run the old and new environments in parallel behind a load balancer and shift traffic gradually, 10%, then 50%, then 100%, watching error rates at each step. This is heavier to set up but reduces the blast radius of any missed bug to a fraction of your traffic.

Consider whether the theme itself should be modernized. If your custom theme predates full-site editing and block themes, migration is a chance to evaluate whether you are carrying forward technical debt or a genuine asset. Not every store should rebuild, but if your theme fights WooCommerce updates every quarter, the migration is a natural decision point. Our take on when to build custom versus lean on existing tooling shows up across our work, from comparing startup development agencies and custom software strategy to the tradeoffs in native app integration versus custom API builds for Shopify.

Advanced checklist:

• Logic extraction: Move theme-embedded post types and functions into a plugin.
• Parallel environments: Consider blue-green deployment for high-revenue cutovers.
• Debt assessment: Decide honestly whether the theme is an asset or a liability.
• Automated deploys: Wire the theme repo to a CI/CD pipeline for future changes.
• Caching strategy: Configure object caching and a CDN on the new host.

If you are just getting started with a fresh store, prioritize setting up a child theme and version control from day one, because doing so makes every future migration a 90-minute job instead of a 3-day ordeal. If you are auditing an existing build before a move, start with Step 1’s audit and Step 2’s verified restore test, since those two steps surface roughly 80% of the risk before you have changed anything. Everything else in this guide is execution once you know what you are working with.

Next Steps:

• Run the build audit: Determine today whether you have a child theme, custom theme, or in-place parent edits.
• Verify a restore: Take a database dump and confirm it restores cleanly into a scratch environment.
• Export your top URLs: Pull your top 200 organic-traffic URLs from Search Console so your redirect map is ready before any move.

Frequently Asked Questions

Can I migrate a custom WordPress theme without issues?

Yes, in the vast majority of cases, and the issues people fear are almost always avoidable rather than inherent. A custom theme is just code and settings, and code and settings move deterministically when you follow a disciplined process: full backup, version-controlled theme, matched staging environment, serialization-safe database move, and end-to-end validation before cutover.

The cases that genuinely do run into trouble usually share a root cause: the customizations were never isolated into a child theme, or a database swap corrupted serialized options, or a license-locked parent theme refuses to reactivate. Each of those is a known, fixable problem, not a reason to avoid migrating.

In our experience, when a custom WordPress theme migration “has issues,” it is almost never the theme’s fault. It is a process shortcut, most often skipping the staging validation pass or using a raw SQL find-and-replace. Follow the seven steps in this guide and the theme itself will behave identically on the new environment.

What happens to my custom theme when I migrate WordPress?

If the migration is done correctly, nothing bad happens to it. Your custom theme is a set of files in `wp-content/themes/` plus a set of settings stored in the database. When you move both faithfully onto a matched environment, the theme renders and behaves exactly as it did on the old site, because it is literally the same code running against the same data.

The theme’s appearance and behavior come from three things: the theme files (templates, stylesheets, `functions.php`), the customizer and widget settings stored in the database, and the media in your uploads folder. Preserve all three and the theme is untouched. Miss one, and the site can load with default styling even though the migration “succeeded” mechanically.

The confusion usually comes from partial migrations. Someone moves the files but botches the database transfer, sees a plain-looking site, and concludes the theme broke. It did not; the settings that told the theme how to look simply did not come across. That is why our Step 3 checkpoint specifically asks you to confirm the site loads with real styling, not a fallback.

How do I preserve custom theme files during migration?

Put the theme under version control before you migrate anything, then deploy it from that repository rather than dragging files around over FTP. Initialize a Git repo in the theme directory, commit the live state, push it to a private remote, and clone it onto the new environment. This gives you a byte-perfect copy, a change history, and an instant rollback path.

Beyond the theme files themselves, remember that WooCommerce template overrides live inside your theme folder under a `woocommerce/` directory, and those must move byte-for-byte along with the rest of the theme. Cataloging them during the Step 1 audit ensures nothing gets left behind.

The database side matters just as much. Your customizer settings, widget configurations, and theme options are stored as serialized data in the `wp_options` table, and they only survive if your domain swap uses a serialization-safe tool. Preserving the files is half the job; preserving the settings that drive those files is the other half.

Will a license-locked premium parent theme cause problems?

It can, and it is one of the most common surprises in a WooCommerce migration. If your child theme sits on top of a premium parent like Divi, Flatsome, or Avada, that parent theme often ties its activation and updates to a license key bound to a specific domain or number of activations. When you migrate to a new domain, the parent may need to be re-licensed or reactivated.

This rarely breaks the site outright, because the theme still functions, but it can block updates and disable premium features until the license is transferred. Before migrating, confirm you have the license credentials and that your license permits activation on the new domain, or that you have activations to spare.

Build this into your Step 1 audit. Record the exact parent theme name, version, and license status so there are no surprises at cutover. A five-minute check now prevents a scramble to find license keys while the site is mid-migration.

How long does a custom WordPress theme migration take?

For a well-audited store with a clean child theme, the hands-on work typically runs 1 to 3 days: a few hours of audit and backup, a day of staging setup and validation, and a short cutover. The variable that stretches this is media size, since transferring a large uploads folder can add hours, and the complexity of the redirect map if you are changing domains or URL structure.

The effective downtime, meaning the window where customers cannot buy, should be under 2 minutes if you stage and cut over properly. That number is short precisely because all the real work happens on staging beforehand; the cutover itself is just redirecting traffic to a site that already works.

Stores with heavy technical debt, in-place parent theme edits, or logic that needs refactoring can take longer, sometimes a week or more, because part of the job becomes untangling how the site was built. That is why the honest audit in Step 1 matters so much: it tells you which timeline you are actually on.

When does it make sense to bring in Presta’s Startup Studio for this?

Candidly, not every store needs an agency for a migration. If you run a modest store, have a clean child theme, are comfortable with WP-CLI and Git, and can tolerate a short maintenance window, you can absolutely follow this guide and do it yourself. Plenty of capable operators do, and we would rather you succeed solo than overspend on help you do not need.

The threshold where it becomes worth bringing us in is usually one of three things. First, revenue: if an hour of downtime costs you more than the migration fee, the risk math favors a team that does this repeatedly and cuts over in minutes. Second, complexity: in-place parent edits, undocumented custom logic, or a migration bundled with a redesign or platform change multiplies the failure surface. Third, SEO stakes: if you depend heavily on organic traffic and a botched redirect map could cost you a quarter of your rankings, professional handling of the URL integrity pays for itself.

At Presta, our Startup Studio team handles exactly these zero-loss, high-stakes migrations, and we treat the custom theme as an asset to protect rather than a risk to work around. If you are unsure which side of the threshold you are on, the fastest path is to get in touch and describe your setup; we will tell you honestly whether it is a do-it-yourself job or one worth outsourcing, and we cover the broader case for that decision in our piece on why you should hire an experienced agency.

Do I need staging, or can I migrate directly to production?

You need staging. Migrating directly to production is the single biggest cause of extended downtime and lost revenue in a custom theme migration. When you build directly on the live server, every bug you hit is a bug your customers hit, and you are debugging under maximum pressure with money on the line.

Staging lets you find and fix problems, the serialized-options failure, the PHP version fatal, the broken checkout, before any customer sees them. The cutover then becomes trivial because you are pointing traffic at a site you have already fully tested, which is how you achieve sub-2-minute downtime instead of a multi-hour outage.

Most quality hosts offer one-click staging, and if yours does not, spinning up a temporary staging environment costs very little relative to the risk it removes. There is no scenario where skipping staging on a transactional store is the right call.

Sources

• WordPress Developer Resources: Child Themes
• WooCommerce Documentation: Template Structure and Overriding Templates
• WP-CLI Command Reference: search-replace
• Google Search Central: Site Migrations Overview
• WordPress Support: Moving WordPress
• web.dev: Core Web Vitals
• Presta: A Systematic Approach to Debugging
• Presta: Journey of a New Website