How to export your content from Optimizely CMS

Yes, an internal team with admin access to the source site can produce the export package, and it is a sensible first step even if a partner runs the rest. The package carries content items, content types, categories, files and visitor groups in .episerverdata format, but that format is specific to Optimizely. A team moving to another CMS still needs to decide how each content type maps to the new model, which items need API extraction, and what happens to personalization. The export itself is the easy part. The judgment about what the target system needs is where internal teams most often run short of time or experience. Before anyone exports, ask for a written inventory of sites, languages, content types and media so you can see what the package will and will not cover.

The main drivers are the number of sites, the number of languages, the count and complexity of custom properties, the amount of personalization, and the volume of media. Each site multiplies the mapping work, and each language adds fallback rules and translated fields to check. Custom properties and block types need a target equivalent, so a heavily customized content model takes longer to map than a standard one. Visitor groups and personalized content have no direct counterpart in most open-source CMSs, so they are rebuilt by hand. Large media libraries add transfer time, link checking and rights review. When you request a quote, ask the provider to list each of these drivers with its count from your environment, so the scope reflects your estate rather than a generic template.

Duration depends on the estate and the decisions made along the way, and no general figure applies to every site. The largest time factors are the content model mapping, the number of test imports needed before the output is accepted, the rebuild of personalization and permissions, and editor review of migrated content. Media transfer and URL redirect planning also add work that is easy to underestimate. Schedules often slip when content owners are not available to approve mappings, so agree on review windows early. Ask any provider for a written plan with named milestones, the number of rehearsal imports included, and the acceptance criteria for each stage. Fixed-scope engagements are usually agreed in writing before work starts, which makes the timeline easier to check against the scope.

It needs three kinds of people. Developers who know the current content model must explain how page types, blocks and properties are used, because the export does not explain intent. An editor or content lead must check migrated content, navigation and media against the live site before cutover. Someone who holds the contract must make scope decisions, approve changes and own the vendor relationship. Expect the developers to spend time on mapping questions and the editor to spend time on review cycles, and plan for both during normal sprints. If the internal developers do not know the target CMS, ask the provider how knowledge will be transferred and documented, and what the team should be able to maintain once the engagement ends.

Yes. Permissions do not survive the import, so roles, editor access, approval workflows and group assignments must be recreated in the target system. Start by documenting the current access matrix from the source site: who can edit which sites, who approves publishing, and who manages users. Map each role to a target role and test it with a small group of editors before full rollout. Visitor group rules used for personalization are a separate rebuild, since they control what visitors see rather than what editors can change. Access rebuilding is a common source of publishing incidents after cutover, so include it in the written scope, name who signs off on it, and keep an audit trail of what was granted and why.

The linked-files option determines how media is handled in the package, and the exact behavior should be confirmed against the Optimizely version you run before you rely on it. In practice, teams need to know whether files travel inside the package or whether the package only references them at their original locations. If files stay linked to an existing storage location, that storage must remain available and under control throughout the migration and for any retained archive. Test the option with a representative subset of pages that use images, documents and video. Check that every file resolves, that metadata such as alt text and captions survives, and that the target CMS serves the files at the URLs you plan to keep. Record the result in the acceptance notes.

An outside partner is worth considering when the estate is large, when the team lacks people who know the target CMS, when the content holds regulated or sensitive data, or when the cutover window is tight. Partners also help when API extraction is needed alongside the package, because the work then includes writing and testing extraction scripts. DeployOpen plans, implements, integrates, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to state in writing what is excluded, which evidence you receive at each stage, and how the handover to your team works. DeployOpen does not publish prices, so request a quote built from that written scope.