What Is This Legacy Tag on My SitecoreAI Site?

What Is This Legacy Tag on My SitecoreAI Site?

Our client called us in a panic that their brand new SitecoreAI site had a LEGACY tag next to it. That's a scary, scary word. Visions of deprecated features, end-of-life timelines, and emergency migration projects were clearly dancing in their heads. We could practically hear the stress through the phone.

Our response? "Relax, guy. It's not a big deal."

And it really isn't. Here's why.

What the Legacy Tag Actually Means

In January 2026, Sitecore made decoupled deployments the default architecture for all new SitecoreAI projects. This was a significant platform improvement that had been in beta since late 2025 and reached general availability on January 29, 2026. As part of that rollout, any project created before January 2026 automatically received a "Legacy" label in the Deploy app. The label simply indicates that the project was built using the original coupled deployment model.

That's it. No deprecation notice. No ticking clock. No impending doom. Your site still works exactly the same way it did yesterday.

The word "legacy" in this context doesn't mean "outdated and unsupported." It means "built before we changed the default." Think of it like a building code update. The house you built last year is still perfectly livable. It just wasn't built to the newest spec.

Coupled vs. Decoupled: What Changed

To understand the tag, it helps to understand what Sitecore actually changed about how projects get deployed.

In the original coupled deployment model, the authoring environment and the editing host were bundled together. When you deployed your project, everything went out as one package. If you needed to update a single component on the editing host, you had to redeploy the entire authoring environment along with it. That meant longer deployment cycles and more moving parts each time you pushed a change.

The new decoupled deployments architecture separates these concerns. Your authoring environment and editing hosts are deployed independently, with their own build processes, their own logs, and even the option to pull from separate Git repositories.

Why Decoupled Deployments Are Better

The practical benefits are meaningful, especially for teams managing multi-site implementations or working across multiple repositories.

Faster deployment cycles. You can deploy editing host changes without redeploying the entire authoring environment. For teams pushing frequent frontend updates, this alone saves significant time.

Independent logging. Authoring environments and editing hosts each get their own deployment logs, making it far easier to troubleshoot issues when something goes wrong.

Separate repository support. Each editing host can pull from its own Git repository. This is particularly valuable for organizations running multiple sites or brands from a single SitecoreAI instance, where different teams may be working in different codebases.

Granular environment control. Teams get more precise control over what gets deployed and when, reducing the risk of unintended changes cascading across environments.

Custom environment variables. You can now set environment variables during project or environment creation, giving more flexibility in how you configure different deployment targets.

In thirty years of building platforms, I've learned that anything that lets you deploy smaller changes independently is almost always a step in the right direction. Smaller deployments mean fewer surprises, faster rollbacks, and happier engineering teams.

How to Convert: It's Genuinely Simple

Here's the part that made our client exhale with relief. Converting from the legacy coupled model to decoupled deployments is straightforward. Sitecore built a conversion tool directly into the Deploy app.

The process looks like this:

1. Open the Deploy app in SitecoreAI.
2. Click on the project you want to convert.
3. Click Options > Convert project.
4. Click Confirm.

That's the whole process. Sitecore will kick off a new deployment of all your authoring environments and editing hosts under the decoupled architecture. The conversion is automated, which reduces the manual effort and the risk of something going sideways during the transition.

One thing to note: if you need to undo the conversion for any reason, you'll need to contact Sitecore Support. So while the convert button is easy to press, make sure your team is aligned before you click it. Coordinate with your developers, confirm that your CI/CD pipelines won't need immediate adjustment, and pick a low-traffic window for the redeployment.

Should You Convert Right Away?

Sitecore recommends that teams actively switch existing coupled deployment projects to the new decoupled architecture. That said, the legacy coupled model still works, and Sitecore hasn't announced any timeline for removing support.

My recommendation? Convert when it makes sense for your team's workflow, but don't panic about the timeline. Here are a few situations where converting sooner rather than later makes good sense:

Your team frequently updates frontend components and is frustrated by long deployment cycles tied to authoring environment redeployments. You're managing multiple sites or editing hosts and want the flexibility of separate repositories. You're onboarding new developers and want them working with the platform's current architecture from day one. You have a natural break in your sprint cycle where a redeployment won't disrupt active work.

If your current deployment process is running smoothly and you're in the middle of a critical release cycle, there's no urgency to convert this week. But putting it on the backlog is wise. The decoupled model is clearly where Sitecore is investing, and aligning with the platform's direction now will save you friction down the road.

The Bigger Picture: SitecoreAI Is Maturing

Stepping back, the introduction of decoupled deployments is a sign of healthy platform evolution. Sitecore has been on an aggressive development cadence with SitecoreAI, and features like this reflect a team that's listening to what enterprise development teams actually need: faster builds, cleaner separation of concerns, and more control over deployment workflows.

The fact that Sitecore built an automated conversion path, rather than forcing teams to manually re-architect their projects, shows thoughtful product design. They understood that labeling thousands of existing projects as "legacy" would cause exactly the kind of phone call we received, so they made the fix as painless as possible.

What We Told Our Client

After walking through all of this, our client's response was something along the lines of "Oh. That's it?"

Yes. That's it. The Legacy tag is cosmetic labeling for a deployment architecture change. Your content is safe. Your site is running. Your investment in SitecoreAI is sound. When you're ready, you click a button, confirm, and your project aligns with the new standard.

No emergency. No migration project. No scary scope estimate.

Just a better deployment model waiting for you when you're ready to flip the switch.