Your team edits pages,
we engineer the parts
We build, upgrade and move Sitecore sites, from long-running XP and XM sites to SitecoreAI, with components your team arranges itself, so page changes stop waiting on a release.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When a page change waits for a release
Some Sitecore sites were built with components editors can’t arrange themselves. A component is one part of a page, such as a banner or a list, built by developers and filled in by editors; where its place on the page is set in code, a new section or a changed layout joins the developers’ queue.
On XP and XM, customizations often run inside the platform itself, in its pipelines and configuration, so every upgrade has to carry them with it. How much there is varies from site to site.
So page changes wait for releases, upgrades wait for time, and a move to SitecoreAI starts by finding what was built where.
What we build
The work on a Sitecore site, laid out so your team can follow it: every customization and integration listed with an owner, and every upgrade and move tried first on a copy, a separate copy of the site kept for testing.
Sites on SitecoreAI
Front ends built on the Content SDK’s Next.js starter, with content delivered from Experience Edge, Sitecore’s GraphQL service, and every component registered for Page builder. Personalization and component tests are wired in as Sitecore’s docs describe them, and the Next.js side is built the way our React & Next.js work builds any app.
XP and XM, kept current
Each site upgraded to the current release, 10.5 today, on the Windows Server, SQL Server and Solr versions Sitecore lists for it, and tried on a copy first. The .NET code around it is written and tested to the standard of our .NET Development work.
From JSS to the Content SDK
JSS front ends on SitecoreAI moved to the Content SDK with Sitecore’s upgrade guides, and components made for the Experience Editor rebuilt for Page builder, so your editors keep editing pages visually.
Moves to SitecoreAI
Your templates, content and components brought across from XP or XM. Customizations that ran inside the platform are rebuilt as webhooks, API integrations or apps, since SitecoreAI takes no custom code of its own inside the platform. One site at a time, where the setup allows.
Components your team arranges
Data templates, components and data sources built together, with rules for where each component can go, so editors place them in Page builder themselves, as the next section shows.
Many sites and languages
Sites and language versions on one instance, with content shared where your teams want it, and language fallback set up as Sitecore’s docs describe it for the platform you run.
Integrations
Experience Edge for delivery, Sitecore’s APIs and webhooks for changes, and Sitecore Connect where its connectors fit, each integration with only the access it needs.
Apps in Sitecore Studio
Custom apps for your own organization, built with Sitecore’s Marketplace SDK, registered in App studio and shown where your team works, Page builder included. Marketplace itself, for apps published to others, is marked coming soon.
AI where it helps
On SitecoreAI, agents in Agentic studio, and assistants connected through the Marketer MCP server, which work within the role of the person who signed in. On XP and XM, Sitecore Stream. SitecoreAI’s AI can be turned off in its portal.
- Connecting any of your systems:Systems & API Integration
- Automation across your tools:Workflow Automation
- Care once it’s live:Support & Maintenance
- Developers in your own team:Hire developers for Sitecore sites
Free to arrange, built to fit
Developers build each component with its data template, the set of fields an editor fills in, and decide which components each area of a page accepts. Sitecore calls these rules placeholder settings: each placeholder, an area of the layout, lists the components allowed in it.
Editors then build and change pages in Page builder, choosing components and content within those rules, with no release. Page builder offers a component only where its rules allow it.
A component’s content lives in its data source, an item that one page can keep to itself or several pages can share, as the site is set up. So editors work quickly, and every page still fits the design and the code behind it.
{{ plAns }}
Editors arrange pages on their own, within the places each component is built for.
{{ plStatus }}
Two platforms, both supported
Sitecore runs two lines today. SitecoreAI is its SaaS platform, launched on November 10, 2025, with XM Cloud at its core: Sitecore runs the platform, and your site’s front end runs where you host it. Sitecore XP and XM, Sitecore Experience Platform and Sitecore Experience Manager, run on your own servers, in containers or on Sitecore Managed Cloud.
Sitecore says XP and XM stay fully supported, with active roadmaps, and that paths to SaaS will be there for each customer at its own pace. XP and XM take a new release from time to time: the latest, 10.5, came out on August 5, 2026, with support for Windows Server 2025, SQL Server 2025 and Solr 10. How long each release is supported is set out in Sitecore’s product support lifecycle article.
On SitecoreAI, Sitecore updates the platform itself. The front end is yours, and takes each new Content SDK release when your team upgrades it, with Sitecore’s upgrade guides.
Headless front ends follow their platform: JSS on XP and XM, the Content SDK on SitecoreAI, where Sitecore’s support for JSS reached its end in mid 2026. On SitecoreAI, the Experience Editor is set to be deprecated from January 1, 2027, with Page builder as the editing experience Sitecore supports.
So each site is kept on a supported release, and a move to SitecoreAI is planned site by site, when it suits the business.
Start with what was built where
The review covers each site: its platform, XP, XM or SitecoreAI, its release and hosting, and where it stands in Sitecore’s support lifecycle; the customizations inside the platform, its pipelines, processors, event handlers and configuration patches, and what each one does; the front end, MVC renderings, JSS or the Content SDK, with their versions; the components, their data templates, data sources and placement rules, and which ones editors can arrange today; the sites and languages, and how content is shared between them; modules from other companies, forms and the platform features in use; each integration, what it reads and writes, its access and the APIs it uses; and roles, workflow and publishing.
The first step is one of three, tried on a copy first: one component rebuilt so editors can place it themselves, one site’s front end moved to the SDK its platform supports, or one upgrade.
You get a written review and a proposal for the first step.
Questions worth asking
Should we stay on XP or XM, or move to SitecoreAI?
It depends on your sites, your team, how much runs inside the platform and how it’s hosted. Sitecore says XP and XM stay fully supported, with active roadmaps, and that paths to SaaS will be available. Keeping each site on a supported release is a sound plan, and so is moving one site at a time when it suits the business. We set out what each would take for your sites, so you decide on your own timing.
How far behind can our XP site be?
Sitecore’s product support lifecycle article sets out how long each release is supported, and it’s the place to check yours. A site on an older release keeps running; what changes is what Sitecore still provides for it. We check where your release stands and plan the move up, tried on a copy first.
What does upgrading to XP 10.5 involve?
Sitecore’s release notes and upgrade guide set it out. XP 10.5 supports Windows Server 2025, SQL Server 2025 and Solr 10, with Solr 10’s Basic Authentication. Its container images are built on Windows Server 2022 and 2025, so container hosts on 2019 move first, and on Azure PaaS, Identity Server now deploys from a template of its own. We run the upgrade on a copy of your site, with its customizations and modules, before it reaches the live site.
We’re on SitecoreAI with a JSS front end. What changes?
The Content SDK is the next major version of JSS for SitecoreAI, and Sitecore’s support for JSS there reached its end in mid 2026. The Content SDK doesn’t support the Experience Editor: visual editing moves to Page builder, so components made for the Experience Editor are rebuilt for it, and Content Editor preview isn’t supported. We follow Sitecore’s upgrade guides, one front end at a time, tried on a copy first.
Can our editors build pages without a developer?
Yes, within the rules each component is built with. In Page builder your editors add, arrange and fill in components wherever the page allows them, and a new page or a changed layout needs no release. We build the components and set where each one can go.
Can one instance run all our sites and languages?
Often, yes. Sitecore can run many sites on one instance, sharing content where you choose, with a language version of each page your team translates. Language fallback, off by default on SitecoreAI, can show an item or a field in another language until its translation is ready. How much to share depends on your brands, teams and markets, so we plan it with you.
What happens to our personalization and analytics when we move?
On XP, personalization and analytics run inside the platform, on its own record of visits. On SitecoreAI, personalization and A/B/n testing work from Page builder, with entry-level access to CDP & Personalize. The two are set up differently, so we list each rule and report you rely on before the move, and plan where each one lives after it.
Can you connect Sitecore to our CRM, commerce or other systems?
Yes. Experience Edge delivers your content through GraphQL, Sitecore’s APIs and webhooks carry changes to and from your other systems, and Sitecore Connect adds prebuilt connectors and recipes where they fit. We agree which system owns each record before anything is connected, give each integration only the access it needs, and try every connection on a copy first.
Can AI assistants work with our content?
Yes, in the ways Sitecore offers for each platform. On SitecoreAI, the Marketer MCP server lets an AI assistant create pages, manage content and set up tests through the Agent API, within the role of the person who signed in, and Agentic studio is where your team uses and builds agents. On XP and XM, Sitecore offers Stream. You can opt out of AI in the SitecoreAI portal, and Sitecore says it doesn’t use customer data to train outside models. We set up only the access each assistant needs.
Can you build apps for Sitecore Studio?
Yes. Custom apps for your own organization are built with Sitecore’s open-source Marketplace SDK, registered in App studio and shown in SitecoreAI where your team works, Page builder included, while you host them. Sitecore’s FAQ marks Marketplace itself, where apps are published for others, as coming soon.
Will our hosting change?
Not unless you choose to change it. On XP and XM, your sites run where they run today: on your own servers, in containers or on Sitecore Managed Cloud. On SitecoreAI, Sitecore runs the platform and Experience Edge, and your front end runs on hosting you choose. Where you run servers of your own, our Cloud, DevOps & Security work covers how they’re set up.
Can you take over our existing Sitecore site?
Yes. The review comes first: we learn what was built where and who relies on it, then pick up the first piece of work you choose, with your own developers if you have them.
How do you keep our sites secure?
Each release’s security fixes go in as Sitecore ships them, tried on a copy first. Roles and workflow decide who can edit and who can publish, and every integration gets only the access it needs. Where a site doesn’t need package installation, we turn it off, as XP 10.5 allows by configuration.
What does it cost?
It depends on your sites, what was built into them and the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire Sitecore developers for our own team?
Yes. We introduce developers who know Sitecore within 48 hours of your request, working in your time zone. You meet them first, and decide who joins.
Sitecore® and Sitecore Experience Manager® are registered trademarks of Sitecore Corporation A/S and/or its subsidiaries and/or affiliates in the United States and other countries, and its other product names on this page may be its trademarks. Webair is independent of Sitecore, and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us which platform and release each of your sites runs. We’ll agree on a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}