Why teams move from Optimizely CMS to Umbraco and what the work involves
Teams usually start this move after a renewal notice, a change to Optimizely's hosting or licensing terms, a data residency requirement, or a decision to run their .NET code on infrastructure they control. The main point to plan for is that a migration is a content model rebuild plus data extraction, not a file copy. Optimizely's export packages can move content items, content types, files and visitor groups, but the content model has to be recreated as Umbraco document types, element types and blocks, and content usually has to be pulled through an API as well. Permissions do not come across, so user roles and editor access are set up again in Umbraco from scratch. The internal .NET team normally owns the work, usually with an implementation partner for the migration itself. The internal team knows the business content, the page templates and the integrations with forms, search and marketing tools. A partner typically handles the extraction scripts, the mapping of Optimizely page and block types to Umbraco equivalents, media transfer, and the redirect plan. Effort and risk depend mostly on how many content types and blocks exist, how much custom Optimizely code sits behind the rendering, and whether personalization must be rebuilt. Ask any provider for a written scope that lists each content type, the media volume, and each integration before agreeing a timeline.
Risk is highest in three places: visitor-group personalization, which must be rebuilt with Umbraco's own tooling or an add-on, URL structure, which needs a tested redirect map so search rankings and bookmarks survive, and editorial workflow, which editors must relearn. Confirm early which Optimizely features your site depends on, because Umbraco's paid add-ons such as Umbraco Engage and Umbraco Forms carry their own licensing terms by domain. Also confirm which Umbraco version you will target. Umbraco 17 is the current LTS release, and the Umbraco end-of-service policy sets out the support windows for each release, so plan the hosting and upgrade path against those dates.
Which Optimizely CMS capabilities map to Umbraco and which need rework
This table maps each main Optimizely CMS capability to its closest Umbraco equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes on what your team must rebuild. Engage and Forms need valid licenses on public domains, so budget for them before you plan the cutover.
| Optimizely CMS capability | Umbraco equivalent | Status and what to confirm |
|---|---|---|
| Page types and content types | Document types with properties and compositions | Clean for simple properties. Confirm property editor mapping for every custom type in your own project. |
| Block types and content areas | Element types in Block List or Block Grid editors | Needs rework. Nested blocks and rendering partials must be rebuilt and tested against each block type. |
| Media assets and folders | Umbraco media library with media types | Needs rework. Export files with the Optimizely extraction tooling, then re-link media references in content. |
| Visitor groups | No direct equivalent in core; rebuild with member groups, segments in Engage or custom code | Gap. Visitor group criteria must be re-specified and rebuilt before go-live. |
| Personalization and A/B testing | Umbraco Engage, a paid marketing add-on with personalization, analytics and A/B testing | Needs rework. Engage requires a valid license covering the production domain and up to two test domains. |
| Forms | Umbraco Forms, a paid add-on | Needs rework. Forms run unrestricted locally but need a valid license on a public domain, one per installation. |
| Multi-language content | Umbraco language and domain configuration per node | Needs rework. Confirm fallback rules and translated property values after import. |
| Headless delivery | Content Delivery API, opt-in and configured in settings | Clean for read-only JSON. Enable it explicitly and confirm preview and member-protected access rules. |
| URL redirects | Umbraco redirect management, configured per URL | Needs rework. Build a full old-to-new URL map before cutover so search rankings and links survive. |
What data to extract and which integrations to rebuild
Moving from Optimizely CMS to Umbraco is mostly a question of what the export package carries and what it leaves behind. The cards below separate the content that a package can move, the content that needs API extraction, the access model that must be recreated by hand, and the connected services that have to be rebuilt on the Umbraco side.
Export packages and their contents
Optimizely exports content as packages in the .episerverdata format, which carry content items, content types, categories, files and visitor groups. This is the fastest route for a like-for-like .NET move because the structure travels with the content. Check each content type against the Umbraco document types you plan to build, since a package does not translate block or property designs into Umbraco's model for you. Ask your partner to run a test import into a staging Umbraco instance before committing to a cutover date.
Linked files option
The linked-files option in the export decides whether media binaries travel with the package or only references to them. Choose it deliberately, because a package without the binaries leaves broken image and document links after import. Confirm the total media size and folder layout before the export, and plan how references will be rewritten to the new media store. Treat media as its own migration stream with its own validation step.
API extraction for the remainder
Anything the package does not carry, and every headless move, needs extraction through APIs. Pull content, relationships and metadata as JSON, then load it into Umbraco through an import script or a migration tool. Umbraco's Content Delivery API is opt-in and returns only published content by default, so plan how drafts, unpublished pages and protected content will be handled. Expect this stream to take the most engineering time for complex block structures.
Permissions and user accounts
Permissions do not survive import, so editor accounts, roles and access rules must be recreated in Umbraco by hand. Map each Optimizely role to an Umbraco user group, and record which sections, node permissions and publishing rights each group needs. Audit who currently holds publish rights, since those accounts often carry more access than their jobs require. Keep a signed-off role matrix as evidence for your access review.
Search, forms and analytics
Site search, form submissions, analytics tags and consent banners usually sit outside the CMS and must be reconnected to Umbraco templates. Inventory each script, form endpoint and search index, then decide whether it will be rebuilt, replaced or retired. Umbraco Forms runs unrestricted locally but needs a valid license on a public domain, so budget that line item. Confirm how submission data is stored and retained before the forms go live.
CRM hooks and identity
Integrations that push leads to a CRM, sync members or authenticate editors and customers must be rebuilt against Umbraco's member and identity model. Document every webhook, API key and single sign-on connection, including who owns each credential. Protected content on Umbraco only serves to authenticated members when member authentication is enabled, so test each login path end to end. Retire old credentials once the replacements are verified.
The migration sequence from inventory to decommission
This sequence moves an Optimizely CMS estate to Umbraco in controlled stages, so each stage produces a checked artifact before the next one depends on it. The order matters because the content model decides what can be extracted, and redirects decide whether search visibility survives the cutover.
Inventory content types, blocks, media and visitor groups
Start by listing every page type, block type, media folder and visitor group in the Optimizely instance, along with the sites and languages they serve. Record which content is published, which is draft-only, and which visitor groups drive personalization. Your Optimizely developers and content owners should review the list together. The output is a content model map that pairs each Optimizely type with a planned Umbraco document type, block or media type, plus an open-questions list for anything that has no clear target.
Confirm the export path for each content source
Decide how content leaves Optimizely. An export package is useful for structure and files, but a migration to another CMS usually also needs API-based extraction of content items, so confirm both paths against your version (CMS 11, CMS 12, CMS 13 or SaaS). Test the export on a copy of the production database, not on live data. The output is a documented extraction method for each content type, with a list of fields that the chosen method does not carry over, such as permissions.
Build and validate a pilot on one site section
Choose one site section with representative page types, at least one block that nests inside a page, and a few media items. Create the matching document types and blocks in Umbraco, load the pilot content, and rebuild its visitor-group rule as an Umbraco segment or equivalent logic. Have editors work through the pilot as they would on the live site. The output is a validated pilot with a written list of mapping corrections that feed back into the content model map.
Transfer content and media in repeatable batches
Run the full content extraction into Umbraco in batches, starting with taxonomy and media, then pages in parent-to-child order so references resolve. Move media files into Umbraco's media library and rewrite internal links and image references to the new IDs or paths. Re-run the import on a fresh target until the output matches the content model map with no unresolved references. The output is a reconciliation report comparing item counts, languages and broken references per content type.
Build the redirect table and test it
Export every public URL from the Optimizely site, including language prefixes and legacy paths, and map each one to its new Umbraco address. Implement the mappings as permanent redirects at the edge or in the Umbraco application, and test a sample from every section against the mapping file. Include error pages and URLs with query strings that carry tracking or filter values. The output is a redirect table and a test log showing that each mapped URL returns the expected status and destination.
Run a parallel period and reconcile changes
Keep Optimizely and Umbraco running side by side on separate hostnames or staging environments while editors and reviewers check content. Decide in advance which system is the source of truth for each change, and reconcile content edited during the parallel period with a final delta extraction. Monitor crawl errors, 404 responses and form submissions in the new environment. The output is a sign-off on content parity and redirect behavior for every section.
Execute the cutover window and sign the checklist
Agree the cutover window with business owners, freeze content edits on Optimizely, run the final delta, switch DNS or the edge routing, and verify key pages, forms, redirects and personalization rules on the live domain. Confirm that licensing for any paid Umbraco add-ons covers the production domain before go-live. The output is a signed-off cutover checklist with named owners for each verification item and a rollback plan that stays valid until the checklist closes.
Decommission the Optimizely environment
After the agreed stabilization period, export a final archive of the Optimizely database, media and configuration, and store it under your retention policy. Then revoke integrations, API keys and service accounts, remove DNS records and certificates, and cancel or reduce the Optimizely subscription or hosting according to your contract terms. Confirm the notice period and exit terms with the vendor in writing before you act. The output is a decommission record listing the archive location, retained access, and the date each service was turned off.
What drives migration cost and duration
This table lists the components that change the price and timeline of moving from Optimizely CMS to Umbraco, with why each one matters and how to shrink it. Read it before requesting a quote, because the same scope written differently can produce very different effort. Quotes follow from a written scope, so the most useful step is to inventory these components in your own environment first.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of page and block types | Each content type becomes an Umbraco document type or element type with its own properties, validation and templates. Blocks with nested structures take more mapping work than flat pages. | Audit unused types before migration, merge near-duplicates and agree the target model with editors before any code is written. |
| Volume of content and media | Item count drives extraction, transformation and verification time. Media with broken or unlinked files adds cleanup, and large libraries increase storage and transfer work. | Archive stale content, define what must move versus what stays in an archive, and confirm which media files are actually referenced. |
| Number of sites, languages and domains | Each site needs its own content tree, hostnames and cultures in Umbraco. Multilingual content multiplies the mapping and review effort per locale. | Confirm which sites and languages are live, consolidate where editors agree, and migrate the highest-traffic site first. |
| Visitor groups and personalization | Optimizely visitor groups do not carry over as configuration. Each rule, audience and personalized block must be rebuilt in Umbraco or in a chosen add-on, and tested. | Export and document every active visitor group, remove retired rules, and decide early whether Umbraco Engage is needed for the same behavior. |
| Custom Optimizely add-ons and extensions | Custom property editors, initialization modules, content providers and third-party add-ons have no direct equivalent. Each one needs a replacement design and code. | List every installed add-on and custom component, then mark which ones are still used by editors or front-end templates. |
| Integrations and front-end rendering | Search, forms, commerce connectors, APIs and custom controllers must be reconnected. A headless or Content Delivery API setup adds consumer changes on the front end. | Map each integration to its owner and endpoint, and decide which ones move unchanged and which are rewritten. |
| Umbraco licensing for Engage and Forms | Umbraco CMS is MIT licensed, but Umbraco Engage and Umbraco Forms need a valid license on a public domain. License scope, domain count and development domains affect the budget. | Decide early which paid add-ons are required, confirm current licensing terms with Umbraco, and count production, staging and development domains. |
| URL redirects and SEO continuity | Every indexed URL that changes needs a mapped redirect. Large URL sets require rules, testing and monitoring after launch. | Export the URL inventory from analytics and search console data, and agree redirect rules before cutover. |
| Editor training and content review | Editors must learn the new interface and verify migrated pages. Review effort grows with the number of templates and locales. | Pilot with a representative section, write editor guides for changed workflows, and schedule review windows before cutover. |
How the migration changes by estate size and starting point
A single site on CMS 11 or 12 that you already host yourself is the closest case to a like-for-like move. You control the database, the file store and the .NET runtime, so you can take a consistent snapshot and run the export tooling in a known state. The export package remains a useful source, but it is designed for Optimizely-to-Optimizely transfers, so most teams treat it as a reference copy and rebuild the content model in Umbraco rather than importing it directly.
- Package export as reference: Use the export to inventory content types, content items, categories, files and visitor groups, then decide which items are worth carrying over.
- Content model rebuild: Map page types and block types to Umbraco document types and element types. Expect this to be the largest design task on a site of this kind.
- Media transfer: Copy the file store directly where possible, then confirm that every referenced file resolves at its new path.
- Single cutover window: With one database and one codebase, freezing editing for a short window is usually simpler than running two editing systems in parallel.
- Personalization rebuild: Visitor group logic does not transfer as a working rule set, so list each group and rebuild its condition in Umbraco or in an add-on.
Confirm with your team which CMS 11 or 12 features the site relies on before you estimate effort, because custom plug-ins drive more rework than content volume.
A multi-site estate on Optimizely DXP usually has several sites sharing one platform, with shared content types, separate environments and a release process run by Optimizely or a partner. Here the migration is a portfolio exercise. Sites with common templates can share one Umbraco content model, while sites with different brands, languages or regulatory needs may need separate instances. Export packages become harder to use as the estate grows, so API extraction usually handles the bulk of content.
- Site inventory first: List every site, its languages, its shared and site-specific content types, and its dependencies on DXP services.
- Shared model decision: Decide early which content types become shared Umbraco document types and which stay per site, because this decision shapes everything else.
- Staged cutover by site: Move lower-risk sites first so the team learns the pipeline before the high-traffic sites move.
- Environment parity: Recreate Development, Staging and Live flows yourself, since Umbraco Cloud's Umbraco Deploy process will not carry over Optimizely environment settings.
- Access and operations ownership: Name who runs hosting, backups and upgrades for each site once the DXP support model no longer applies.
Ask your partner to show how shared content types and redirects will be tested across sites before work begins.
A customer on the hosted Optimizely CMS has no server to snapshot and no file system to copy, so the primary route is extraction through APIs. Content is read as structured data, media is downloaded as files, and the new Umbraco site is built to receive that data. The export package is generally not the main path. Confirm with Optimizely which API access, rate limits and export permissions your subscription includes, because these determine how long extraction takes and whether it can run in one pass.
- API extraction as the main route: Script reads of content items, their properties, their locale versions and their publishing state.
- Media download: Pull assets with their metadata and keep a mapping from old URLs to new paths for later redirects.
- Incremental sync: Plan for a final delta run during cutover so content edited after the first pull is not lost.
- Structural rebuild: Recreate the content types and block structure in Umbraco, since extraction moves data, not the model.
- Redirect map: Build the redirect table from the old URL structure before launch, because SaaS URL patterns often differ from the target.
Before committing, ask for a sample extraction of several page types so you can see how blocks, references and localized fields come through.
What usually goes wrong and how to prevent it
Most failed Optimizely to Umbraco migrations do not fail on content transfer. They fail on the details around it: URLs, personalization, editor access, media paths, add-on licensing and version timing. Each card below names one of these failure points and the check that prevents it.
Lost SEO equity from missing redirects
Optimizely page URLs, friendly URLs and legacy paths rarely match the new Umbraco document structure unchanged. Every indexed URL that returns a 404 after cutover gives up the ranking and links it earned. Build a full URL inventory from analytics, search console and server logs, map each old path to a new target, and test the redirect table on staging before DNS changes. Confirm how the chosen Umbraco hosting or reverse proxy handles 301 rules.
Personalization that silently stops
Optimizely visitor groups and personalized content blocks do not carry over as working logic. Umbraco has no native equivalent to every Optimizely targeting rule, so pages can render the default variant without any error. Inventory each visitor group and personalized block, decide which ones Umbraco Engage will rebuild, and test each audience with real profiles on staging. Ask the implementation partner to document what was rebuilt and what was dropped.
Permissions and editor roles not carried over
Export packages do not preserve user accounts, group membership or access rights, so editors arrive in Umbraco with no permissions or with overly broad ones. Map each Optimizely role to an Umbraco user group, define section and document-level access, and remove accounts for leavers before the first editing session. Keep an approval record of who signed off the role matrix, since auditors often ask for this evidence.
Media links broken after transfer
Images and files referenced by content can resolve to old Optimizely storage paths, and file names or folder structures may change during import. Editors then see placeholders on live pages, or the links expose assets that were meant to be retired. Decide whether media is copied into the Umbraco media library or served from a storage location you control, rewrite references in a dry run, and crawl the staging site for broken asset URLs.
Unplanned Umbraco license needs
Umbraco CMS is MIT licensed, but Umbraco Engage and Umbraco Forms carry their own licenses once they run on a public domain. Forms run unrestricted locally, while public use needs a valid license, sold per domain and covering subdomains. Engage needs a license covering one production domain and up to two development or testing domains. Before you choose add-ons to replace Optimizely personalization or form features, list every production, staging and subdomain you will publish on and get the license scope confirmed in writing.
Umbraco version and support timing
Umbraco 13 reaches end of life on December 14, 2026, so a project that starts now on that line will need an upgrade soon after launch. Umbraco 17 is the current LTS release, with end of life on November 27, 2028. Current Umbraco documentation requires .NET 10.0 or higher. Pick the target version against your .NET hosting plan and your upgrade budget, and put the upgrade path into the project plan from day one.
When to target Umbraco 17 and how support dates affect the plan
Target Umbraco 17 if you want the longest documented support window for a migration that goes live now. Umbraco 17 is a long-term support release published on November 27, 2025, with end of life on November 27, 2028, end of Extended Long-Term Support on November 27, 2030 and end of service on Umbraco Cloud on November 27, 2031. Umbraco 13, the previous LTS release from December 14, 2023, reaches end of life on December 14, 2026, so a project that lands on Umbraco 13 in 2026 would need an upgrade within a short period. Current Umbraco documentation also requires .NET 10.0 or higher, which means your hosting image, build pipeline and developer workstations must move to .NET 10 as part of the same project, not later.
Read the end-of-service policy before you sign off the plan. It states that hosting continues on Umbraco Cloud for the duration of Extended Long-Term Support, a phase of up to 24 months, and that projects can then run on dedicated resources for 12 months after XLTS ends. If you self-host, the Cloud dates matter less than the end-of-life and XLTS dates, but they still signal when Umbraco stops offering the hosted path. Your plan should name the upgrade you expect to run after go-live, with a budget line for the .NET developers who will perform it, and the team should agree which LTS line the site will move to next.
Before fixing the plan, confirm the current dates and the .NET requirement directly with Umbraco, using the Umbraco end-of-service policy and the requirements page for the version you select. Ask whether Umbraco 17 remains the recommended LTS for your go-live window, which add-ons such as Umbraco Engage or Umbraco Forms your licenses must cover on each production and test domain, and whether any package you need supports the .NET version in use. Record the confirmed dates and the answers in the migration plan so that the cutover date, the post-launch upgrade window and the end of your Optimizely support are all tied to documented facts.
What teams ask before migrating from Optimizely CMS to Umbraco
What drives the cost of migrating from Optimizely CMS to Umbraco?
The cost depends mostly on how much content, how many page and block types, how many integrations and how much personalization logic has to be rebuilt. The Umbraco CMS software itself is MIT licensed and free, so the one-time spend is labor: discovery, content modeling in Umbraco document types and blocks, front-end rebuild, data extraction, testing and redirects. Recurring costs are hosting, the .NET developers who maintain the site and any paid Umbraco add-ons. Ask any partner for a written scope that lists page types, block types, content volume by site and language, integrations and personalization rules, then compare quotes against that same list.
How long does an Optimizely to Umbraco migration usually take?
Duration depends on the same drivers as cost: the number of content types, the volume and languages of content, the complexity of the front end and how much personalization must be rebuilt. No duration figure is supplied for this migration, so treat any timeline you receive as an estimate that depends on the written scope. A useful plan separates discovery and content modeling, extraction and media transfer, front-end rebuild, parallel testing and cutover. Ask for milestones and acceptance criteria for each phase rather than a single end date.
What does our internal team need to provide for the migration?
The migration needs people who know the content in detail, not only the platform. Typically this means an editorial owner who can confirm which content is current, a product owner who decides which personalization rules still matter, and developers who can access the existing Optimizely environment and the target Umbraco environment. Your team should also provide access to analytics, a list of integrations, the current URL structure with traffic data, and an agreed approach to legal and security review. Confirm these responsibilities in the written scope so that delays do not become disputes.
Can our own developers migrate from Optimizely CMS to Umbraco without a partner?
Yes, a capable .NET team can do the work, and Umbraco's documentation and open source code are available for that purpose. The practical questions are capacity and experience: the team must model content, build the front end, write extraction and import code, rebuild visitor-group logic and run redirects and testing without disrupting live traffic. Many teams split the work, handling content and front end internally while bringing in outside help for extraction, cutover or a specific gap. Decide this by comparing the skills you have against the list in your written scope.
What moves automatically when we move from Optimizely CMS to Umbraco?
Very little moves without work. The Optimizely export package in .episerverdata format is a backup of Optimizely content, but it is not a drop-in import for Umbraco, so content is usually extracted through APIs and mapped to Umbraco document types and blocks. Media files need their own transfer and re-linking. Templates, page logic, forms and personalization are rebuilt rather than copied. Ask each partner or internal lead to show which items they expect to automate and which they will rebuild by hand, and confirm how each is verified after import.
How are permissions and visitor groups handled during the move?
Permissions do not survive an export and import, so editor roles, access rights and workflow assignments must be recreated in Umbraco through its own user and group model. Visitor groups do not transfer as working personalization either. Each rule must be reviewed, re-expressed as Umbraco logic or as a marketing add-on configuration, and tested with the audience it was meant to serve. Umbraco Engage provides personalization, analytics, A/B testing and targeted campaigns as a separate paid add-on, so decide early whether you need that capability or a simpler rebuild.
What licensing applies to Umbraco add-ons such as Engage and Forms?
The Umbraco CMS repository is published under the MIT license, but some add-ons are commercial. Umbraco Engage requires a valid license covering one production domain and up to two development or testing domains to run on a public domain. Umbraco Forms runs unrestricted locally but needs a license on a public domain, sold per domain, which also covers subdomains and includes two development or testing domains, with one license per installation. Confirm the current terms with Umbraco before budgeting, because add-on pricing and licensing are not part of the open source CMS license.
Does Umbraco version support affect when we should migrate?
Yes, the release you target determines how long you have before the next upgrade. Umbraco 17 is a long-term support release published on November 27, 2025, with end of life on November 27, 2028. Umbraco 13 reaches end of life on December 14, 2026, so teams still on that line should plan a move. Current documentation requires .NET 10.0 or higher, so check your hosting and developer skills against that requirement. Confirm the support dates on Umbraco's end-of-service page before you set a plan.
Running Umbraco after go-live: hosting, backups and upgrades
The first post-migration decision is where Umbraco runs. You can host it yourself on infrastructure you control, with either SQLite or SQL Server as the database, or you can use Umbraco Cloud, a managed service that runs on Microsoft Azure with Development, Staging and Live environments, automatic backups, a global CDN and HTTPS. Umbraco Deploy synchronizes content and structure between those environments. Self-hosting gives you full control over network placement, data residency and patch windows, but your team owns the Windows or Linux servers, the .NET runtime, the database, the CDN and the monitoring. Umbraco Cloud moves much of that work to the vendor, at the cost of working inside its environment model. Ask each option for a written list of what the provider backs up, how often, how long copies are kept, and how a restore is tested. Confirm the target .NET version with the current requirements page before you size servers, because Umbraco's documentation requires .NET 10.0 or higher for current releases.
Backup responsibility depends on the hosting choice, so write it down before go-live. On self-hosted installs, your team must back up the database, the umbraco/Media folder, and any custom configuration and code, and must test restores on a schedule. Umbraco Cloud documents automatic backups, but you should still confirm retention periods and whether they cover your add-on data. Upgrade planning is the other recurring task. Umbraco 17 is an LTS release published on November 27, 2025, with end of life on November 27, 2028. Umbraco 13 reaches end of life on December 14, 2026, so any site still on it needs a dated upgrade plan now. Read the end-of-service policy for the phases that follow, and budget testing of your Engage and Forms add-ons, since those carry their own licensing.
A support retainer makes sense when the internal team cannot absorb the recurring work: applying LTS upgrades, patching the .NET runtime, running restore tests, and keeping security scanning in the release cycle. Fixed-scope engagements suit the one-time work of standing up hosting, backups and a runbook after migration. A retainer suits the ongoing work, and the written scope should name the upgrade windows, the environments covered, the restore test frequency and who responds when a site is down. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ask for a quote built from a written scope rather than a standard price.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Optimizely to Umbraco move, that means a written scope first, then a build that runs in infrastructure you control, with handover documentation and optional ongoing support.
How we scope
- Inventory the Optimizely CMS version, page and block types, visitor groups, media libraries and multi-site setup before quoting
- Agree which content, templates, personalization rules and redirects are in and out of the migration
- Confirm the Umbraco version, hosting target and database choice, such as SQL Server or SQLite, in writing
- Fix deliverables, acceptance criteria and timelines in a written scope before any work starts
How we build
- Map Optimizely page and block types to Umbraco document types and element blocks, with a sign-off step per content type
- Extract content through the source APIs and export packages, then load it into Umbraco with repeatable import scripts
- Move media files and verify references, then rebuild visitor-group personalization using Umbraco's own features or add-ons
- Build and test a redirect map covering every URL that has search or inbound traffic
How we hand over
- Deliver the migration scripts, content mapping specification and redirect table as versioned project files
- Document the self-hosted deployment, backup routines, configuration keys and rollback steps for your operations team
- Run editor walkthroughs and a parallel-run review so content owners can confirm published pages before cutover
- Record which Optimizely features were not carried over so licensing and business decisions are visible
How we support
- Offer ongoing support, upgrades and continuous testing for the Umbraco site as a retainer after handover
- Plan upgrades around Umbraco's published LTS and end-of-life dates, confirmed with Umbraco before each cycle
- Keep security testing of the public site and APIs available as a separate scoped engagement
- Confirm response expectations and any service levels in the retainer agreement before signing
