• As part of a Sitecore 9.3 to 10.3 upgrade, we replaced self-hosted Solr with a managed SolrCloud service, on a codebase shared by three development teams working in parallel.
• The real challenge wasn't the migration itself, but fitting it into an already mature release process without disrupting it.
• A new security requirement meant releases needed to run from a specific network. We solved that without paying for idle infrastructure.
• Profiling the new release flow led us to a set of pipeline optimizations that ended up speeding up releases significantly, for every team on the platform.
For the past several years, I've been working as part of the development team at a German digital agency, on a long-running project for a multinational company. Our team builds the client's B2B websites and maintains the platform as a whole, running on Sitecore XP, while the B2C side is developed by a separate team. It's a large, actively developed platform. Alongside the client's own in-house team, developers from the agency - including myself, seconded through ALLWIN's Time & Material model - and another development partner all contribute to it in parallel. Between the three groups, work spans everything from platform support to marketing-driven features like marketing automation, Salesforce integration, and email campaigns, running across several concurrent, smaller and larger projects at any given time.
About two years ago, this shared codebase went through one of its bigger milestones: an upgrade from Sitecore 9.3 to 10.3. I want to walk through one piece of that project in particular, replacing our search infrastructure, because it's a good example of a problem that looks like a straightforward technology swap on paper, but turns out to be mostly about process once you're actually the one doing it on a live, multi-team platform, as a T&M developer embedded in someone else's team.
As part of the upgrade, we moved away from Solr hosted on Azure App Service and adopted SolrCloud, managed by SearchStax. On the surface, this reads as a single line item: swap one search backend for another. In practice, it touched almost everything around it.
We had to move from a classic Solr schema to a managed schema, a different way of defining and evolving how content gets indexed, with its own constraints on what you can change and when. We updated the Sitecore-side search configuration to match. And because SearchStax lives outside the network boundary our platform normally operates in, we had to add a new security layer on top: IP filtering combined with HTTP basic auth, so that only requests from known, trusted sources could reach the search cluster.
None of those pieces were, on their own, the hard part. What made the project genuinely demanding was that the platform already had a mature, well-established release process, one the whole team relied on and trusted, and this change had to fit inside it, not sit next to it or replace it. Config and schema updates, collection changes, alias creation: all of it needed to be release-able through the same pipeline, with the same reliability guarantees, as everything else on the platform. Nobody on the team wanted a "special case" step bolted onto the side of an otherwise predictable process.
As the DevOps engineer on the team, I was involved from early planning through the actual implementation of that release flow, figuring out where search-related changes belonged in the existing pipeline structure, and what needed to change in the pipeline itself to make room for them. In parallel with the Sitecore upgrade, we also migrated the platform's classic DevOps pipelines to YAML pipelines, which turned out to be the foundation a lot of what came next was built on.
We didn't want to configure SearchStax by hand through its dashboard, so we built scripts against both the SolrCloud API and the SearchStax API instead. These scripts take whatever changes are tracked in our repository, schema definitions, collection configuration, and apply them to a given environment. The same scripts run inside our pipelines during a release.
This gave us two things at once. First, a process any of us could run and test from a local machine, without waiting on a pipeline run just to check whether a change worked. Second, a process we could still fully orchestrate and control centrally through Azure DevOps, so releases stayed consistent and auditable no matter who triggered them.
The IP filtering requirement added its own wrinkle. Because deployments to SearchStax have to originate from a machine on an allow-listed network, we couldn't just run our release scripts from any standard pipeline agent. We needed compute that lived on that specific network.
We settled on Azure Virtual Machine Scale Sets for this. Keeping a dedicated VM running permanently on the allow-listed network would have been secure, but wasteful. Scale Sets let instances spin up only when a release actually needs them, and scale back down afterward. That kept the security requirement satisfied without leaving infrastructure, and its associated cost, running idle in the background between releases.
Once the new release flow was in place end to end, we didn't stop there. We profiled it. Looking at where release time was actually going, we found that most of it was spent on I/O operations: reading and writing files, waiting on network calls, that kind of overhead. So we optimized for that directly, instead of guessing at what "felt" slow.
Three changes made the biggest difference: grouping related tasks so they didn't each pay their own setup cost, parallelizing jobs wherever their dependencies allowed it, and caching external dependencies so they weren't re-fetched from scratch on every single run. None of these are exotic techniques individually, but applied together, and specifically where the profiling data pointed, they added up.
Moving to Sitecore's then-latest version gave the team access to the newest platform features, fixes, and optimizations directly from Sitecore. It also made ongoing platform maintenance noticeably easier day to day. Future version upgrades, hotfixes, and support requests to Sitecore all became more straightforward once we were current rather than several versions behind.
On the search side specifically, the switch to a clustered, multi-node SolrCloud setup with automatic backups made search hosting meaningfully more reliable than the previous single-instance Solr setup had been: fewer single points of failure, and a proper backup story where there hadn't really been one before.
The change I'm personally proudest of, though, is the release time itself. We cut it down significantly. For the client, that meant faster deployments and, in theory, a shorter feedback loop for every development team working on the platform, not just ours. For our own team, it meant something very concrete: whoever was on deployment duty for production releases, which happen outside business hours, simply had to spend less time doing it.
Self-hosting Solr on Azure App Service meant we were responsible for scaling, node management, and backups ourselves. Moving to SearchStax's managed SolrCloud offloaded that operational burden to a service built specifically for running Solr at scale, in exchange for adapting our schema and release process to work with it.
A single always-on VM on the allow-listed network would have satisfied the IP filtering requirement, but it would also have meant paying for compute that sits idle between releases. Scale Sets let us spin up exactly the capacity a release needs, only when it's running.
Yes, indirectly. The search-related release steps were folded into the same pipeline everything else already used, instead of being handled as a special case, so the pipeline optimization work (task grouping, parallelization, caching) benefited every release on the platform, not just ones touching search.
Ádám is one of the ALLWIN developers working on long-term Time & Material engagements with our partners. Projects like this one are typical of that model: a long-term, embedded role on a partner's team, working inside established processes rather than starting from a blank slate, a skill set our T&M developers build up over years on the same platform, alongside their technical expertise.
