Published on Sep 15, 2026 | Updated on Sep 15, 2026
Phase 3: Build the WordPress Foundation
With your plan ready, it’s time to build the WordPress environment. Think of this like building a house before moving in furniture. The structure and rooms need to be in place before you move content in.
Set Up Hosting and Your Environments
Once you’ve chosen a hosting provider in Phase 2, the next step is setting up three separate environments:
- Development: where your team builds and experiments freely, without any risk to a live site
- Staging: a near-identical copy of what will go live, used for testing (User Acceptance Testing) before launch
- The Live (production site): the actual public-facing site your visitors and customers see
This setup matters because it lets your team build, break, and fix things in Development without any risk, test the real thing in Staging before anyone outside your team sees it, and keep Live stable throughout the entire migration process.
Most managed WordPress hosts include staging environments as a standard feature.
Create Your Content Models
After you’ve created a list of content types in Sitecore, it’s time to build those content types in WordPress. It’s here that you decide what types of content models you want to build – pages, posts, custom post types, etc.
While mapping the content models, you can also streamline the content workflow compared to what you followed in Sitecore WorkFlows. WordPress reduces the number of stakeholders involved and eases the process overall.
Develop Templates and Components
When you’ve had all the content models listed, this is where you can start creating the templates and layouts in WordPress.
In Sitecore, pages are built from layouts (the overall page structure), sublayouts (reusable sections within a layout), and renderings (individual components, such as a hero banner or a testimonial block).
WordPress’s equivalent is the block editor (Gutenberg), where pages are built from blocks, and Full Site Editing (FSE), which extends that block-based approach to entire page templates, headers, and footers using reusable patterns.
Here’s how the layout/template translation works:
| Sitecore Concept | WordPress Equivalent |
| Layout | Page template (via FSE or a theme) |
| Sublayout | A block pattern or template part (header, footer, section) |
| Rendering | An individual Gutenberg block, or a custom block if built specifically for your site |
When it comes to designing, you have two options here:
- Continue the existing design: This can be picked when you rebuild the existing website design in WordPress. Keeping the same design can actually be a good idea since you’ll be reducing the extra work that’ll go into planning and creating a new design alongside the platform switch.
- Revamp the design: This could be a good idea too if you want to revamp the website’s design completely. However, redesigning the website from scratch can be treated as a separate project rather than mixing it up with the migration process.
If you want a redesign, the safer sequence is: migrate first with design continuity, stabilize on WordPress, then redesign as a second, independent project once the platform itself is proven stable.
Integrate and Configure Your Integrations
Start connecting WordPress to your CRM, analytics, marketing automation platform, and any other connected systems using the integration map from Phase 1.
Set these up in your Development or Staging environment first. Never build and test integrations directly on the live site. Test each connection thoroughly:
- Do form submissions correctly reach your CRM?
- Are analytics events firing and tracking correctly?
- Is data flowing both directions where needed (e.g., personalization data from a CDP)?
Document each integration as you configure it, including API keys, webhook URLs, and any custom code involved. This documentation becomes essential if something breaks post-launch and you need to troubleshoot quickly.
Take a Backup of Sitecore
Now, while you are designing and building integrations in WordPress, make sure you take a backup of your Sitecore environment – the database, media assets, and site configuration.
This backup will be a safety backup if something goes wrong or a look-back place when someone wants to see what the site looked like in the past.
What You Should Have When This Phase Is Done
By the end of Phase 3, you should have:
- Development, staging, and live environments set up and confirmed working
- Content models (post types, fields, taxonomies) built in WordPress
- A decision made on design continuity vs. redesign, with existing design rebuilt if that’s the path chosen
- Templates and components rebuilt as Gutenberg blocks or FSE patterns. A defined, tested content approval workflow
- Integrations connected and tested in a non-live environment
- A complete, verified backup of your Sitecore environment
With these things in hand, you’re ready for the “migration”: actually moving your content across, without losing the SEO value it took years to build.
Published on Sep 15, 2026 | Updated on Sep 15, 2026