The smart way to plan your SitecoreAI migration

A practitioner's guide to designing an AI-ready digital experience strategy, content architecture, and martech stack to deliver on the promise of a SitecoreAI build.

I recently wrote an article for Sitecore.com about the five steps that make a migration deliver — drawing on a digital experience strategy and readiness program I ran with Colliers International ahead of their move from Sitecore XP to SitecoreAI.

That article had about 1,000 words to cover five major decisions. This article has more room, because I make the rules around here (which means about double, but it's worth it).

So here is the same framework with the depth that practitioners actually need, and the harder context that a vendor publication is not quite the right place for.

Each step corresponds to one of five focused workshops sessions I ran with Colliers' global digital and marketing team in Sydney in March 2026. This is not a theoretical digital transformation framework. It is what we actually did, what we found, and why it mattered.

STEP 1

Digital experience strategy before platform decisions

'Start with strategy' is advice that gets ignored or misunderstood constantly. Let me be specific about what it means in a migration context, because it is not the same as writing a strategy document.

Before Colliers could make a single useful decision about user experience, content structure, or migration sequencing, they needed answers to four questions that sit at the heart of any digital experience strategy:

• Who are the priority audiences for this platform, and what does a genuinely better experience look like for each of them?
• Where is the business losing value from digital today, in leads, in conversions, in content efficiency, in team confidence?
• What would make this rebuild undeniably successful in 18 to 24 months, in terms that finance and leadership would recognise?
• What kind of digital experience does this organisation need to be providing, not just at launch, but in three years?

Pre-workshop survey results

The pre-workshop survey gave us a clear mandate. SEO and LLM visibility was the top 18-month priority for 76% of respondents. More qualified leads came second at 56%.

The factor ranked most critical to digital experience success was not platform capability or technical architecture — it was a clear and shared vision:

That tells you exactly where to start. A migration that begins with platform decisions before the experience vision is agreed will spend the entire program reworking those decisions as the strategy catches up.

Designing for three users, not one

Most migration programs are designed around the end customer. That is necessary - but not sufficient. Effective digital orchestration requires designing for three distinct user groups simultaneously:

• Customers and prospects — the commercial audience, whose experience is the primary objective
• Internal users — the marketers, editors, and content producers whose ability to work efficiently directly determines the quality and consistency of the customer experience
• Machine users — the search platforms, AI tools, data pipelines, and APIs that consume structured content to power personalisation, discoverability, and AI-assisted workflows.

When you design only for the customer, you get a front-end that might look good but is expensive to maintain and poorly equipped for AI. When you design for all three, the platform becomes substantially more capable, and it stays that way because this approach doesn’t just deliver performance, but efficiency.

I will shout this from the rooftops: user experience in your DXP is the upstream enabler of performance for customers. Users who are frustrated by wasting time on simple, repetitive tasks don’t have the bandwidth to do the innovative, creative work which will drive your digital experience forward.

The North Star

We ended Session 1 with a shared North Star statement. Not a brief, not a set of requirements, but a single, clear, agreed direction. For organisations running multi-market, multi-team programs, getting that statement agreed before any technical decisions are made is itself a significant achievement. It creates the kind of alignment that no specification document can produce.

STEP 2

Objectives and measurement defined before the build

What 'success' actually means

Measurement planning is one of the most commonly deferred activities in a migration program. Most programs are measured at launch: did we go live? Is the site up? Is anything broken? Those are hygiene questions. They do not tell you whether the migration delivered value.

Effective DX strategy requires defining measurable outcomes, by audience and by business objective, before the build begins. Not vague targets, but specific, benchmarkable numbers that can be reported to leadership with confidence.

For example:

• Not 'more qualified leads' — but '25% more qualified leads from the institutional investor segment within 12 months of launch'
• Not 'better content engagement' — but '40% higher engagement with research content, measured by time on page and scroll depth, benchmarked against the current 90-day average'
• Not 'improved search performance' — but 'first-page ranking for 15 target non-branded service terms within 6 months'
• Not 'faster publishing' — but 'reduce average content-to-publish cycle time from 5 days to 1 day for standard editorial content'

Those numbers matter for two reasons. First, they give the technical team clear requirements, as the platform architecture must support the measurement infrastructure those outcomes depend on. Second, they give the business a credible, evidence-based case for the investment. Executives approve budgets for outcomes, not for features.

Building for Day 2 on Day 0

This is a principle I return to constantly in martech strategy work: the decisions you make on Day 0, before the build begins, determine what Day 2 looks like. If the measurement infrastructure is not designed in from the start, you spend the first six months of the new platform's life trying to instrument it after the fact.

Mapping which data connections needed to be in place at launch — not retrofitted later — is also a direct input into AI readiness. AI-powered features depend on clean, connected data signals. Measurement architecture and AI readiness are not separate workstreams. They are the same workstream.

STEP 3

Planning for AI and optimisation before you go live

Where vision and reality diverge

In most digital transformation programs, the gap between what the platform can do and what the organisation actually delivers is not a technology problem. It is a foundations problem.

SitecoreAI's agentic capabilities are a compelling example of this. Agentic Studio can automate the assembly and personalisation of page experiences at scale, connecting the right content to the right audience without manual intervention for every variant.

The Sitecore.com team recently used exactly this capability to run a highly targeted ABM campaign, assembling nearly 100 personalised page experiences automatically from structured content building blocks. Previously, these pages were assembled with significant manual effort and were quickly out of date, but the programmatic creation of content becomes operationally viable when the model is designed to support it.

Agentic AI does not replace good content architecture. It rewards it.

But those capabilities depend entirely on what you bring to them. To really benefit from the capabilities of AI, your CMS needs:

• Structured, modular content: properly modelled fields with meaningful values, not pages of unstructured marketing copy
• Consistent taxonomy: so the system can reliably classify, relate, and surface content across markets and service lines
• Connected data signals: so personalisation decisions are based on actual visitor behaviour and declared intent, not guesswork
• Clean entity relationships: so AI tools know that this author belongs to this service line, covers this geography, and has published this research.

The third session in the Colliers program mapped exactly those requirements before a single component was designed. The result is a platform that is genuinely AI-ready at launch — not eventually, once the taxonomy is fixed and the data stack is connected.

Addressing nervousness about AI and data governance

Nervousness about AI, data privacy, and how content will be consumed by AI systems is entirely reasonable, and one of the most common concerns I hear from senior marketing and technology leaders. The right response is not to defer those questions. It is to build the answers into the architecture from the start.

Gartner's 2026 marketing predictions found that 62% of CMOs say AI-driven automation has already forced them to rethink which roles are essential in their function. The nervousness is real, widespread, and worth designing for — not deferring.

SitecoreAI's Model Context Protocol (MCP) offers a structured answer. Rather than leaving it to AI systems to infer what your content means and who it is for, MCP allows you to provide that context explicitly, within a governed framework that your organisation controls. That is a meaningfully different posture to 'AI is doing something with our content and we are not sure what'.

STEP 4

Marketing data architecture mapping

Current state to future state

The Marketing Data Architecture Mapping (MDAM) session is the one most migration programs skip entirely, and the one that most often determines whether the investment in a new platform delivers its intended value.

The session mapped two states: the current state: the real picture of what data exists, where it lives, how reliable it is, and where the gaps are; and the ideal future state aligned to the audiences and objectives agreed in the earlier sessions. The future state was structured around two layers:

• Systems of contextual knowledge – the platforms and data sources that hold what you know about your audiences, content, and performance
• Systems of contextual delivery – the platforms that use that knowledge to deliver personalised, optimised experiences, including decisioning and personalisation tools

The gap between current and future state becomes the input to platform design and integration planning. Doing that mapping before the build means the gaps are addressed deliberately, not discovered after launch.

The MCP opportunity

One of the most significant near-term AI opportunities for any organisation moving to SitecoreAI is Model Context Protocol (MCP). Here is what it makes valuable:

• AI systems receive explicit, structured information about your content – what it means, who it is for, what entity it relates to – rather than inferring it from ambiguous text that was written for humans, not machines
• AI-powered search becomes markedly more accurate, surfacing the right content for the right query instead of returning results based on keyword proximity alone
• LLM visibility improves – when a prospect asks an AI assistant about your services, products, or areas of expertise, your content is more likely to surface as a credible, structured answer
• Internal AI tools – Copilot, ChatGPT, Claude, Gemini, and SitecoreAI itself – generate better outputs because they are consuming clean, structured, governed source data
• AI-powered personalisation and agentic workflows become reliable, not approximate, because the content context is explicit rather than inferred.

For organisations with deep expertise content such as research, thought leadership, product or service information, and industry analysis, MCP is not a future capability. It is an immediate, accessible opportunity. But it requires the data architecture and content structure work to have been done first.

How it works - from original content to AI-cited authority

STEP 5

Tackling content structure, taxonomy, and schema before migration

Content structure is infrastructure

Content structure is not a content project. It is infrastructure. It is the foundation on which search, personalisation, generative, agentic and RAG AI, and DAM governance all depend. And it is the thing most migration programs either underprepare or defer.

Most senior marketing teams I work with have a strong instinct for editorial quality but less familiarity with content architecture. Simply put, it is the structural decisions that determine how content is modelled, classified, and consumed by both humans and machines.

The smart teams are catching up fast, because AI has made content structure commercially consequential in a way it never was before.

The Colliers digital marketing team had a strong foundation of content quality and domain expertise. What they needed was a clear understanding of what AI and LLMs require from content structure, and the practical frameworks to design that structure themselves. Because that is the key shift: this is not something you leave to developers to figure out anymore. (Read more: Why Marketers (Not IT) Must own the AI Data Layer)

Taxonomy must be owned by the business

Taxonomy is the shared language of your platform. It determines how content is classified in the CMS, how assets are organised in the DAM, how search facets are structured, how analytics events are categorised, and, reflected in your JSON-LD schema, how AI systems interpret and generate content on your behalf.

A taxonomy designed only by technical teams, without deep input from the marketers and content owners who understand the business, produces a classification system that is structurally sound but commercially inaccurate.

McKinsey's recent research on AI data readiness makes the same point from the other direction:

Only 7% of companies have fully scaled AI across their organisation, and more than two thirds of the high performers say data, not the technology, is the primary obstacle.

McKinsey, AI data readiness (2026)

Taxonomy is exactly the same problem, just closer to home. Taxonomy isn't just a CMS field - it's the controlled vocabulary that has to run consistently across your CRM, your DAM, your analytics platform, your campaign tagging, and your personalisation engine, every system downstream that touches content or customer context. When marketing and content teams own that vocabulary, every one of those systems inherits a shared, commercially accurate language. When it's left to whichever team happens to be building a platform at the time, you get a different definition of "audience" or "region" in every tool, and nothing downstream can be trusted.

McKinsey’s prescription is for enterprise data that is governed, reusable, traceable, and owned by people who understand what the data means rather than just where it lives. A CMS taxonomy nobody outside IT understands has exactly the same failure mode as a data model nobody outside IT understands. It works technically but fails commercially.

Marketers need to understand how taxonomy is used in order to design it well. This is a new area of responsibility for many marketing teams, but it is not a difficult one, and the payoff is significant.

The design principles we applied with Colliers are ones I use with any enterprise client:

• Global consistency — core taxonomy terms that apply across all markets and properties or services, ensuring that the same concept is classified the same way everywhere
• Regional flexibility — domain-specific terms, dictionaries and translations that allow individual markets, service lines, or product categories to classify content in ways that are meaningful for their context
• Business ownership — taxonomy decisions made by the people who understand the commercial context, not inherited from a legacy system or delegated entirely to a development team

You cannot get good taxonomy from developers alone. And you cannot get good search, good personalisation, or good AI without good taxonomy.

Schema markup turns your taxonomy into context

Structured schema markup is a clean data layer that tells search engines, LLM and AI systems what your content means, not just what it says, and therefore it is also becoming the responsibility of smart marketers. Output as JSON-LD in your head, there is a lot of room for creating a data structure that will build your authority, accuracy and traffic, and will help you deliver on the promise of AI.

Most large enterprise sites have some schema in place. Most of that schema is incomplete, inconsistently applied, or missing the fields that matter most for AI discoverability: author, date, product or service, audience type, content format, geographic relevance, etc.

Those gaps are exactly what AI systems fill in with guesses – this is where that whole confidently wrong part comes in.

Marketers and content owners need to understand schema markup well enough to give their technical teams specific, informed requirements. Developers can implement schema and validate it, but they cannot tell you which fields are commercially meaningful. That knowledge lives in the business.

I have written a detailed walkthrough of how to audit and improve your schema markup for SitecoreAI. It is a practical, step-by-step guide that any content or digital marketing team can run, and at a basic level it is the exercise I ran live with the Colliers team.

The Colliers commitment

Colliers committed to doing the content audit, taxonomy design, and schema work before the build began. The result will be a faster, cleaner migration that arrives at the new platform with clean, structured, contextually rich content – the exact foundations that SitecoreAI's search, personalisation, and agentic features need to perform. In the meantime, they’ll get early benefits from this work before the migration, providing quick wins that will help build momentum towards the re-platforming.

"We could have pushed the taxonomy and schema work to phase two. A lot of programs do. What made us commit to doing it first was understanding that these weren't just migration tasks – they were the foundations that search, personalisation, and AI all depend on. We'll see the benefit before we've migrated a single page."

Grant Carroll, Global Head of Martech & Digital Strategy, Colliers

What this preparation makes possible

The organisations that get the most from a digital transformation investment of this scale are not the ones with the biggest budgets or the most ambitious roadmaps. They are the ones who invest seriously in the decisions that determine what the platform can do, before the build begins.

Effective DX strategy is not about platform selection. It is about clarity: on audiences, on outcomes, on data, on content structure, and on the governance that keeps all of those things working as the business evolves. That clarity is what separates a migration that delivers from one that disappoints.

Colliers invested in getting those foundations right. That investment will pay back in a migration that is fast and clean, a platform that performs at launch, and AI and agentic features that actually deliver from day one, not eventually.

If you are preparing for a platform migration and want to think through what this digital orchestration and readiness work looks like for your organisation, I would be glad to talk it through.

Want to know more?

Everything in this article – taxonomy design, schema markup, AI readiness, measurement architecture – these are now marketing responsibilities, not technical ones. The organisations getting ahead of this aren't waiting for their developers to figure it out. They're building the capability in their own teams.

That's exactly what my upcoming Content with Context program is designed for. Delivered live with a cohort of your peers, it’s straight-forward, practical, and built on 20+ years of enterprise delivery. The marketing, digital and content practitioners attending will learn how to design a content structure and taxonomy that works for search, for AI, and for the people who have to maintain it.

And if this is the conversation your team, your clients, or your event audience needs to be having, I work with organisations to bring it into workshops, roundtables, and campaigns that open doors with digital leaders, please get in touch or connect on LinkedIn.

→ Read the Sitecore.com version of this story: sitecore.com/resources/insights/customer-insights/colliers-sitecoreai-migration