Notcutts - WordPress blog migration to Magento 

Notcutts is a family-owned group of garden centres. Originally founded in 1897 by horticulturalist Roger Crompton Notcutt in Suffolk, it has remained in the Notcutt family for more than a century.

Today, Notcutts operates a network of 19 garden centres across England and a thriving website, offering a wide range of garden plants, outdoor furniture, homeware, pets and wildlife products, gifts and more. Many locations also include restaurants and visitor amenities to enhance the customer experience.

The company grew from a small nursery into one of the UK’s leading garden retail brands, known for combining gardening advice, quality products and a destination shopping experience. Their heritage includes participation in national horticultural shows and early contributions to the garden centre concept in the UK.

Notcutts highlights its passion for gardening, its inspiration from nature, and the expert advice it shares with customers, while upholding its family values and strong commitment to customer service and community engagement.

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.

A controlled migration that preserved SEO and simplified the platform

• 234 posts deployed from staging to production
• 246 SEO rewrites prepared to preserve search equity
• Blog and Magento now run as a single-platform Magento solution
• Migration executed as a sequence of low-risk, reversible steps
• Client maintained control over pacing via staging validation and phased sign-offs
• Operational complexity reduced by removing a separate CMS platform from the runtime path

What This Demonstrates (For Prospective Clients)

• Enterprise-grade planning: Migration playbooks that include SEO, data, code, rollback.
• Zero-drama launches: Slipstream and phased deploys over "big bang" releases.
• Technical pragmatism: Automate where it’s safe; go manual where IDs and templates create hidden risk.
• Comms discipline: Close coordination with account management and stakeholders to keep decisions fast and informed.