Sitecore Explorer Deprecation: Content Mode Migration Guide
Sitecore announced on 2 September 2026 that Explorer will no longer be available from 22 September and that Page builder Content mode replaces its core content creation and discovery workflows. For teams that use Explorer to find, create, edit, version and publish content, this is an editor operating-model change with a short preparation window.
The content itself is not being moved to a new CMS. The practical task is to prove that people can complete their real jobs through the right SitecoreAI interface, with the same permissions, workflow controls, language behaviour and publishing outcomes.
This guide is for Sitecore owners, marketing and content leaders, experienced authors, operations managers and technology decision-makers. It explains what changes, which workflows need testing, where Content Editor still fits and how to run a controlled transition.
Three facts to put on the migration plan
Treat this as an authoring-workflow cutover, not a simple menu change.
22 September
Sitecore's dated changelog says Explorer will no longer be available from this date.
Content mode
Page builder Content mode becomes the supported experience for common creation, discovery and field-editing tasks.
Content Editor remains
Advanced and administrative scenarios may still need Content Editor, depending on roles and implementation.
Resolve the date discrepancy first
Sitecore's dated changelog says Explorer will no longer be available from 22 September 2026. At the time this article was checked, Sitecore's Explorer and Manage content documentation pages displayed 1 October 2026.
Do not turn that inconsistency into extra project time. Use 22 September as the internal readiness date, confirm the applicable timing for your tenant with Sitecore or your implementation partner, and keep the evidence with the change record. Planning to the earlier published date is the lower-risk choice.
Why this matters to the business
An editor who cannot find the right item, complete an approval step or publish the intended language version can delay campaigns and create production mistakes even when the platform is technically healthy. Common risks include editing the wrong same-named item, missing a field, using an over-privileged account as a workaround, publishing a wider reference set than intended, or discovering during a deadline that a task belongs in Content Editor.
The migration therefore belongs to marketing operations and CMS governance as much as it belongs to the implementation team. Pair it with clear ownership, short task-based training and a support route for edge cases. VaniTech's guide to CMS governance for marketing teams provides a useful operating-model foundation.
Move editors through a controlled seven-step cutover
Map Explorer tasks to the right destination
Start with observed work, not a generic feature list. Ask editors to show how they complete weekly and monthly tasks in Explorer, then assign each task to Content mode, Page builder Editor mode, Content Editor or another specialist application.
| Current task | Primary destination | What to verify |
|---|---|---|
| Create a folder, page or content item | Content mode or Page builder Editor mode | Correct parent, insert option, template, name and permissions |
| Find an item and edit fields | Content mode | Search accuracy, same-name items, field visibility and write access |
| Create a content-item version | Content mode | Version naming, workflow state and publishing availability |
| Edit a page visually | Page builder Editor mode | Components, data sources, layout, preview and device behaviour |
| Manage advanced structure or workflow | Content Editor | Role access, ownership, procedure and escalation path |
| Publish content or pages | Page builder or Content Editor | Language, references, related items, subpages and final workflow state |
| Publish a whole site | Content Editor | Scope, target, timing, permissions and operational approval |
Do not promise that every Explorer screen has a one-to-one replacement. Sitecore describes Content mode as the destination for common workflows and explicitly retains Content Editor for advanced or administrative scenarios.
Use the simplest interface that safely completes the task
A clear routing model reduces training time without hiding necessary controls.
Content mode
Use for focused creation, flat search, field editing and content-item versions when the task does not require visual page composition.
Editor mode
Use for page layout, components, data sources, preview, personalisation and other work that needs the page canvas.
Content Editor
Retain for advanced tree, structure, workflow, security, full-site publishing and implementation-specific administration.
Test content discovery, not just editing
Content mode uses a flat search across the content tree. This can be faster than navigating deep hierarchies, but Sitecore notes that same-named items can appear more than once and the search results do not show the item path. That is a real governance concern in multisite and multibrand estates.
Build test cases around ambiguous names such as Home, Hero, Contact, Terms, Campaign or Product. Confirm how an editor distinguishes site, language, collection, environment and item type before changing content. Where ambiguity is persistent, improve display names, naming conventions, templates, instructions or the content model instead of expecting every editor to remember hidden context.
Also verify insert options. Content mode only offers the templates configured for the selected item. If a page or folder cannot be created, the correct fix may be template or insert-rule configuration rather than broader permissions.
Validate permissions with real editor accounts
SitecoreAI combines organisation and app roles with item-level access rights. Read, Write, Rename, Create and Delete affect what people can do in the content tree, while Field Read and Field Write can change which fields they see or edit. Language rights add another boundary.
Administrator testing is therefore insufficient. Use representative accounts for authors, reviewers, publishers, translators and advanced users. For each role, test both allowed and denied behaviour. Confirm that a workaround does not require granting broad Content Editor or administrative access to people who only need a focused authoring task.
Keep a simple role-to-task matrix showing the approved interface, content roots, languages, workflow commands and publish capability. This becomes the support team's first diagnostic when an editor reports that an item, field or action is missing.
Rehearse versions, languages and workflows
Sitecore documents that content-item versions can be created, edited and published from Content mode. On a workflow-enabled site, a new version enters the first workflow state and must move through the configured states before it can be published.
Test the exact sequences your business uses: create a new version, edit a versioned field, edit an unversioned or shared field, switch language, submit for review, reject, approve, set publishing availability and publish. Verify which changes affect one version, one language or every language.
A scheduled availability window is not the same as automatic publication. Sitecore says the version still must be published during the specified interval. Make ownership explicit for time-sensitive launches.
Include concurrent editing
Page builder autosaves and supports concurrent field-level work. Two users editing different fields can proceed, but edits to the same field can create an overwrite decision, while concurrent layout changes can require a reload. Include these cases in training so editors do not treat a warning as a generic error or overwrite a colleague's work without checking.
Test publishing scope end to end
Page builder can publish content items, pages, page and partial designs and selected related items. A page publish can also include subpages, references and language versions. Content Editor remains available for item and whole-site publishing, while other specialised objects may publish from their own tools.
For each common scenario, record what is expected to reach Experience Edge and what must remain unchanged. Then verify both sides: the intended content is live, and unrelated content, languages, subpages or references were not unintentionally included.
- Publish one standalone content item.
- Publish one page without subpages.
- Publish selected related items only.
- Publish one language while another remains unchanged.
- Attempt to publish an item that is not in the final workflow state.
- Publish a time-limited version during and outside its availability window.
- Confirm the approved route for a whole-site or emergency publish.
Keep publishing evidence in the cutover record: item IDs, languages, reference scope, workflow state, job result and a live-page check.
A practical transition test matrix
| Scenario | Expected result | Evidence |
|---|---|---|
| Author finds two same-named items | The correct site, language and item are identified before editing | Search result and selected item details |
| Author creates a child item | Only approved templates are available and the item lands under the correct parent | Parent ID, template and item path |
| Restricted author opens sensitive content | Denied content or fields remain unavailable | Role, item and observed access |
| Translator switches language | The intended language version is created or edited without changing another language | Before-and-after values by language |
| Reviewer advances workflow | Only permitted commands appear and the state changes correctly | Workflow state history |
| Publisher selects references | Only approved items and languages reach Experience Edge | Publish job and live verification |
| Two editors change one field | The conflict is understood and resolved without accidental overwrite | Warning and final field value |
| Advanced task needs Content Editor | The documented escalation route works with least privilege | Task owner, role and completion record |
Run the matrix in a safe non-production environment with production-representative templates, roles and content structures. Repeat a smaller smoke test after the tenant change.
A seven-day readiness plan
Day 1: Inventory Explorer users and tasks
Identify active users, frequent tasks, critical campaigns, languages, workflow roles and any documented Explorer procedures.
Day 2: Map every task
Assign each task to Content mode, Editor mode, Content Editor or another SitecoreAI app. Record edge cases and gaps.
Day 3: Validate roles and configuration
Check app access, item and field permissions, language rights, insert options, templates and workflow commands with representative accounts.
Day 4: Run the test matrix
Use real content types and record evidence for creation, search, editing, versions, languages, workflow and publishing.
Day 5: Train with short task cards
Replace screen tours with five-minute instructions for high-frequency jobs. Include when to stop and use Content Editor or contact support.
Day 6: Confirm ownership and communications
Name the platform owner, content lead, publisher and technical support contact. Confirm the applicable retirement timing with Sitecore.
Day 7: Cut over and monitor
Move routine work to Content mode, keep an exception log and review search, permissions, publishing and training issues daily during the first week.
Questions for Sitecore or your implementation partner
- Which retirement date applies to our SitecoreAI tenant: 22 September, 1 October or a tenant-specific rollout date?
- Which Explorer tasks in our implementation are fully supported in Content mode today?
- Which tasks should remain in Content Editor, and which roles need that access?
- Do our item, field, language and workflow permissions behave identically through the replacement interface?
- How should editors distinguish same-named search results across sites, languages and content roots?
- Are any custom fields, editors, extensions or content-tree conventions affected?
- What publishing scope is used for content items, pages, references, languages and whole-site operations?
- What monitoring or support information should we collect if an editor cannot complete a task?
If the platform has accumulated unclear ownership or undocumented customisation, this transition is a useful point for a broader CMS review and support handover. The goal is a reliable authoring system, not merely replacing one navigation link.
Sources checked
- SitecoreAI changelog: Explorer deprecation and Content mode replacement
- Sitecore documentation: Explorer
- Sitecore documentation: Create and find content
- Sitecore documentation: Publish content in SitecoreAI
- Sitecore documentation: Work with versions
- Sitecore documentation: Editing in Page builder
- Sitecore documentation: Access rights
- Sitecore documentation: Workflows and the Workbox
- Sitecore documentation: Content Editor