Migration guide
Can you migrate SharePoint to Optimizely?
Last updated: · By the Replatform Radar team — specialists in pre-migration CMS content audits
Yes — you can migrate a public-facing site or intranet off SharePoint onto Optimizely, and in most cases you should, because SharePoint was built as a Microsoft collaboration and document-management platform rather than a web content management system. The move is less a like-for-like port and more a rebuild: SharePoint pages, web parts, and list/library data have to be re-modeled as Optimizely content types and blocks. The upside is a purpose-built .NET CMS with proper templating, publishing workflow, and marketing tooling; the cost is that little of the SharePoint front end carries over unchanged. Plan it as a content and information-architecture project, not a file copy.
SharePoint is frequently pressed into service as a public website or a heavily customized intranet, but it was designed around document libraries, lists, and team collaboration. Its pages are assembled from web parts and its content lives in libraries and list items, which makes structured, reusable web content awkward to model and even harder to present with clean, SEO-friendly markup. Teams typically outgrow it when they need real editorial workflow, flexible page composition, multilingual delivery, or performance and design control that SharePoint pages do not provide.
Optimizely (formerly Episerver) is a dedicated .NET content management platform built around strongly typed content types and composable blocks. Migrating means designing an explicit content model in Optimizely, mapping SharePoint pages and library items onto it, and rebuilding templates and navigation. Because both platforms sit in the Microsoft/.NET ecosystem, authentication and hosting can align well, but the content architecture and editing experience are fundamentally different and need to be redesigned rather than transferred.
In depth
What a SharePoint to Optimizely project actually looks like
A realistic shape for this specific transfer. Phases, the work inside each, and the failures that recur on this exact platform pair. Spans assume a mid-size estate; large or multi-site estates run longer.
- Content and audience auditWeeks 1-4
- Separate genuinely public content from internal collaboration material; SharePoint estates mix both, and the public subset is usually far smaller than stakeholders expect.
- Inventory document libraries by usage: which documents are current, which are superseded, and which exist only because nobody deleted them.
- Map list-based content that behaves like structured content (directories, events, policies) - these become Optimizely content types rather than pages.
- Record the permission model, since a public CMS replaces audience-targeted visibility with either publication or authentication, not per-item ACLs.
- Model and governance designWeeks 4-8
- Design Optimizely content types for the structured lists, and decide what remains a document download versus what becomes real web content - the biggest quality win in this migration.
- Replace SharePoint's site-collection sprawl with a deliberate information architecture; a literal translation reproduces the navigation problem that prompted the move.
- Decide the document strategy: which files migrate to Optimizely media, which stay in SharePoint behind authentication, and how the two are linked.
- Establish publishing workflow and ownership, because SharePoint's implicit 'whoever owns the site' model does not carry over.
- Build and migrationWeeks 8-16
- Rebuild web parts as Optimizely blocks; there is no port path, and many web parts turn out to be unnecessary once content is properly modelled.
- Migrate documents with metadata via the Microsoft Graph API into Optimizely media, converting high-traffic PDFs into web pages where the content deserves it.
- Re-implement search: SharePoint search behaviour and relevance differ from Optimizely's, and users notice immediately.
- Rebuild any InfoPath or Power Apps forms on a supported forms approach - these are often discovered late and block launch.
- CutoverWeeks 16-22
- Build redirects from SharePoint URLs, including the long auto-generated paths, to the new structure; these URLs are ugly but are genuinely linked and bookmarked.
- Verify authenticated versus public boundaries carefully - accidental publication of internal material is the highest-consequence failure in this migration.
- Run a document-link sweep: references between documents and pages break constantly when libraries are restructured.
Pre-launch verification checklist
The checks worth running before DNS moves. Each one maps to a failure we see repeatedly on SharePoint to Optimizely projects.
- Nothing internal is publicly reachable - verified by crawling the new site as an anonymous visitor, not by reviewing configuration.
- Documents that were superseded are retired rather than migrated, and current versions are the ones linked.
- High-traffic PDFs that answer common questions exist as real web pages, since documents are poorly served in search and AI answers.
- SharePoint URLs with real traffic or inbound links redirect to the correct new pages.
- Search returns sensible results for the queries staff and the public actually use, tested against a real query list.
- Forms submit end to end, including any downstream workflow that previously ran in the Microsoft stack.
- Structured data exists on the content types where it matters - policies, events, directories - which SharePoint never emitted.
Risk register
| Risk | Likelihood | Mitigation |
|---|---|---|
| Internal content accidentally published | Medium | Crawl as an anonymous user before DNS moves and treat any unexpected result as a launch blocker. |
| Document dump migrated wholesale instead of curated | High | Gate migration on a usage threshold and require an owner for every retained document. |
| Site-collection sprawl reproduced in the new IA | High | Design the information architecture from user tasks, not from the existing SharePoint structure. |
| Search quality regression noticed immediately by staff | Medium | Benchmark real queries on both platforms before cutover and tune relevance ahead of launch. |
| InfoPath or Power Apps forms discovered late | Medium | Inventory every form in the audit phase; they are frequently invisible until someone reports a broken process. |
FAQ
SharePoint to Optimizely: frequently asked questions
Can you migrate from SharePoint to Optimizely?
Yes. Public sites and intranets are regularly moved from SharePoint to Optimizely. Expect a rebuild of pages and templates rather than a direct import, since SharePoint web parts and lists map onto Optimizely content types and blocks by hand.
Is SharePoint a good public website CMS?
Generally no. SharePoint is built for collaboration and document management, and using it as a public web CMS limits markup control, SEO, editorial workflow, and design flexibility, which is why teams move to a dedicated platform like Optimizely.
What happens to SharePoint document libraries in the migration?
Library files become media assets in Optimizely, and library metadata columns are mapped to media properties. Folder structures rarely map one-to-one, so plan the asset taxonomy deliberately and build redirects for the old document URLs.
Do SharePoint workflows and forms carry over to Optimizely?
No. SharePoint Designer workflows, Power Automate flows, and InfoPath forms have no Optimizely equivalent and must be rebuilt with custom code or an external forms and workflow tool as part of the project.
Further reading
- SharePoint — official site
- Optimizely — official site
- Google Search Central — site moves with URL changes (how to keep URLs and their traffic intact through a move)
- Our own measurements — 27,385 live sites, from a 48,588-domain sample
Before you migrate SharePoint to Optimizely, know exactly what breaks.
Scan your site →