Notcutts - WordPress blog migration to Magento 

A migration plan that covered the whole system, not just content.

We produced a detailed migration playbook that explicitly defined:

• 
  Data sources and target mappings (posts, categories, tags, authors, media)
• 
  SEO approach (rewrite generation and validation)
• 
  Deployment sequencing (code vs content vs final cutover)
• 
  Rollback procedures (including keeping both platforms available during transition)

This made the migration repeatable, testable and auditable, rather than a one-off "best effort".

Phased deployment instead of a "big bang"

We deliberately split the work into phases that each ended in a stable, transactional live site:

• 
  Pre-deploy preparation (everything that can be done off-line)
• 
  Live code deploy (install BlogMX alongside WordPress)
• 
  Live content deploy (migrate content safely and verify)
• 
  Cutover (switch URLs and disable FishPig integration)
• 
  Decommission (remove WordPress in a later deploy)

This structure let the client pause between phases for review, testing, and stakeholder
sign-off without risking excessive downtime.

Slipstreaming: Run both blogs side-by-side on live

The key risk reducer was a "slipstream" approach:

• 
  WordPress remained live and serving `/garden-advice`, whilst the client prepared blog content on the staging site.
• 
  BlogMX was installed and configured on production, but initially mounted at a temporary URL, so it didn't conflict with the existing WordPress blog.
• 
  Only when BlogMX was visually and functionally verified did we switch the final URL over.

Result: no cliff-edge launch moment; the "launch" became a controlled URL flip.

Dry-runs in non-production to surface surprises early

We used local and staging/UAT to rehearse the migration steps, validate SQL dumps, confirm media paths, and verify URL rewrite behaviour - so unexpected issues happened in controlled environments, not during a live deployment window.

The result was a smooth deployment with minimal downtime and no surprises.

Phase A: Pre-deploy preparation (minimise live downtime)

Code preparation:

• 
  Added tooling to export/import CMS content reliably (MSP_CmsImportExport) on UAT.
• 
  Created a release branch and merged all required blog/migration changes early.
• 
  Resolved conflicts and stabilised the release branch ahead of any production action.

Data preparation

• 
  Exported CMS pages/blocks from UAT
• 
  Produced a BlogMX SQL dump (BlogMX lacks a first-class export/import)
• 
  Prepared redirect mapping for WordPress → BlogMX URLs (246 rewrites)

Media preparation

We copied BlogMX media assets from UAT to live before cutover to avoid "missing image" regressions.

Phase B: Live code deploy (no functional change for customers)

• 
  Initiated a content freeze to prevent drift during migration
• 
  Enabled a Cloudflare maintenance page only when required
• 
  Took a full live DB backup, just in case (which was removed later, as per data security requirements).
• 
  Deployed the release branch to production
• 
  Disabled maintenance page

At this point:

• 
  WordPress still served the live blog
• 
  BlogMX was installed and ready for configuration and content migration

Phase C: Live content deploy (migrate and validate)

• 
  Exported CMS blocks on live (as a safety snapshot)
• 
  Imported CMS blocks/pages from UAT without overwriting existing live content
• 
  Migrated BlogMX content via direct SQL import (single-run, tightly controlled)

Imported in dependency order:

• 
  Authors → categories → tags → posts
• 
  Configured BlogMX at temporary blog URL

Verified:

• 
  Frontend rendering and layout/styling
• 
  URL rewrite behaviour (no loops, no 404s, correct canonical patterns)
• 
  Content completeness and media integrity

Pragmatic content-layer decisions

For elements prone to ID collisions and brittle DB mapping, we chose high-signal, low-risk manual recreation:

• 
  Rebuilt 32 widgets on live (avoids cross-environment ID mismatch)
• 
  Recreated 8 PageBuilder templates cleanly in production once the base CMS content was in place
• This avoided the common trap of "perfect automation" that introduces subtle production bugs

Phase D: Cutover (when the client was ready)

• 
  Changed BlogMX URL from temporary path to the final `/garden-advice`
• 
  Disabled FishPig integration (so WordPress stopped serving the blog route)
• 
  Imported/generated the final set of rewrites

The cutover was intentionally small, reversible, and performed only after full verification.