Optimizely to WordPress: What Marketing and IT Teams Should Agree Before the Move
Prepare an Optimizely to WordPress brief covering reusable blocks, languages, integrations, editor needs and launch ownership before requesting a proposal.
In this article
Original editorial illustration of the topic; not a client screenshot or finished-product demonstration.
Marketing may want faster publishing while IT is thinking about integrations, access and the systems connected to the website. An Optimizely to WordPress project needs both views. Otherwise, a website that looks complete can still leave editors without a familiar workflow or remove functionality another team depends on.
This checklist is for businesses and agencies preparing a migration brief, including legacy Episerver installations. The aim is to agree the website boundary and acceptance criteria before comparing proposals. My Optimizely to WordPress service starts with product-specific assessment and a representative content review, followed by an agreed implementation scope.
Name the product and the website boundary
Begin with the actual Optimizely product, version and deployment. Identify the public sites and language versions in scope, the team responsible for the source platform and the access available for discovery. A legacy Episerver website, a traditional CMS installation and a SaaS setup should not be treated as interchangeable source systems.
Then describe what WordPress will replace. The public marketing site may be only one part of the organisation’s stack. Identify customer portals, business applications and other products that remain in service. Ask for a dependency diagram or written inventory that names each system owner. This turns “replace the CMS” into a project boundary that people can review and price.
Turn marketing needs into editing tasks
Ask editors what they actually publish: campaign landing pages, product information, news, resource downloads or regional content. Record which patterns are reused and which changes require help today. Define what a better workflow should let them do, such as launching an approved landing-page layout without rebuilding its design.
For a WordPress destination, agree the content types, reusable Elementor templates and fields needed for those tasks. Include realistic material in the demonstration: long headings, repeated blocks, a downloadable document and content used in more than one place. Marketing sign-off should cover the editing process as well as the public appearance. A new layout alone does not define how shared content is maintained.
Give reusable blocks and languages an explicit destination
The Optimizely CMS 12 documentation describes exports involving content items and associated resources. That is a source capability, not a direct import into WordPress. The migration still requires a destination map for retained fields, blocks, assets and relationships. Discovery must check the source version and the material available from your installation.
Make shared blocks and language rules visible in that map. Decide whether a reused value stays shared, becomes a destination content record or is intentionally repeated. Agree ownership of translated pages and their URLs. Ask the developer to demonstrate one translated page that uses reusable content before approving the full transformation. Record exceptions instead of silently simplifying editorial behaviour.
Create a feature decision register with IT
| Dependency | Decision to record |
|---|---|
| Forms and CRM | Fields, destination records, routing owner and acceptance test. |
| Search | Content sources, filters, supported service and relevance review. |
| Personalisation or experimentation | Retain, replace, rebuild or retire—with an accountable owner. |
| Identity and restricted content | Access requirements and a separately approved implementation plan. |
| Analytics and consent | Required events, tools, approvals and release verification. |
Each row should have an owner, proposed destination and completion check. The website quote should distinguish existing connections from new integrations. If another supplier owns a dependency, agree its involvement before assigning a launch date. This helps the team compare a complete website implementation with an offer that covers only content and layouts.
Use a pilot as a buying milestone
A useful pilot contains ordinary and difficult content. Choose a campaign page, a reusable-block example and a language or integration case. Ask for a demonstration of the imported values, public layout and editor tasks. The pilot should produce findings and a confirmed mapping, with unresolved items listed for a decision.
This can be a sensible first engagement when the source is poorly documented. Agree what discovery delivers and how those findings affect the next quotation. A prototype screenshot is not enough to establish archive coverage or integration readiness. Give the approving marketing and IT contacts the same sample and record what each person is accepting.
Plan release ownership across both teams
Agree the final publishing window, the content changes allowed during development and the person responsible for reconciling them. Assign ownership of redirects, metadata, DNS, hosting and deployment. The launch checklist should include the actual enquiry and publishing journeys that support the business, with any test communications approved in advance.
Define the conditions for proceeding, delaying or recovering the release. After launch, identify who reviews broken links, crawl findings, integrations and editor questions. A migration can change search performance even when it has been carefully planned; the proposal should describe monitoring and ownership rather than promise a ranking outcome. Separate the release support period from an ongoing maintenance arrangement.
Prepare the assessment request
Send the website URL, product/version if known, site and language inventory, important page types and the dependency register. Explain the business reason for the move, who approves content and the timing constraints. If an agency is coordinating the project, state whether it supplies the design, content model or implementation requirements.
I can work remotely with your team to assess a defined Optimizely or Episerver migration to WordPress. The next step is an agreed discovery scope or implementation proposal, with retained systems, third-party costs and responsibilities made visible. Public links and a brief outline are sufficient to begin the conversation.
Related planning: Sitecore to WordPress Migration: What Marketing and IT Teams Should Agree First · AEM to WordPress Migration: Scope, Redirects and Launch Planning for US Businesses · Joomla to WordPress Migration Cost: What to Include Before Requesting a Quote.
Official references, reviewed 24 October 2026: Optimizely CMS 12 export and import.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
