Accelerating Optimizely CMS and Commerce upgrades with agentic AI (Part 1 of 2)

How Niteco's Upgrade Machine uses orchestrated AI coding agents to deliver a buildable baseline and a running CMS, then hands over for stabilization and deployment. 

Niteco Engineering | Engineering Insights | 10 min read

Blog series 

This is Part 1 of a 2-part series on accelerating Optimizely upgrades with agentic AI. 

TL;DR 
We built an Upgrade Machine: an agentic AI system composed of a main orchestrator, specialized subagents, and a growing skills library. It compresses the most repetitive phase of an Optimizely upgrade by producing a PR-ready codebase that builds successfully in Release mode and boots the CMS backend cleanly on the target platform. 
From that point, a Niteco delivery team takes over to stabilize integrations, validate behavior, and ship to production, typically within two to six weeks depending on footprint. 

An Optimizely upgrade is rarely just a package update. It touches runtime assumptions, custom code, integrations, routing, dependency injection wiring, configuration, content models, and cutover readiness. The CMS 11 and Commerce 13 move to CMS 12 and Commerce 14 is a major inflection point because it sits on top of a broader platform modernization. Patterns that were stable for years can suddenly require structural refactoring. 

There is also a lifecycle reality. Optimizely has communicated end-of-support timing for CMS 11 and Commerce 13 in 2026. Many teams reference an end-of-support window starting in April 2026, with an extension to October 2026. The exact dates and entitlements can vary, so you should verify against official Optimizely lifecycle communications and your agreement. The practical implication is consistent: delaying this upgrade increases platform risk because vendor support and patch cadence wind down. 

In our experience, the true schedule killers are discovery gaps: undocumented integrations, legacy helpers, and configuration wiring no one wants to touch. These gaps force teams into slow compile-fix cycles and late-stage runtime surprises. Our objective with the Upgrade Machine is straightforward: remove the repetitive refactor grind from the critical path and give engineers a clean, buildable baseline to stabilize from. 

Rule-based upgrade tooling is genuinely useful for deterministic transformations. Retargeting frameworks, aligning package references, updating project files, and applying known API substitutions should be automated. Most upgrades should start there, and ours do. 

The gap appears when upgrades meet context-heavy work: cross-file refactors, ambiguous intent, or situations where multiple fixes could compile but only one aligns with the correct platform pattern. A rule engine cannot reason about intent. It either applies a transformation safely or escalates. In practice, those escalations accumulate into a multi-week manual backlog. That is the territory where agentic AI changes the economics. 

The Upgrade Machine is an orchestrated setup of AI coding agents operating inside a controlled workflow. 

Two design choices matter most. 

First, autonomy with guardrails. Agents can run autonomously, but only within a workflow that enforces checkpoints, reviewer gates, and escalation thresholds. When uncertainty is high, the system pauses and asks for a developer’s decision rather than guessing. 

Second, compounding knowledge. Every engagement adds patterns to the skills library. The system improves because it is built to capture what works, validate it across multiple cases, then promote it into safe automation. 

For this post (Part 1), our definition of done is narrow and measurable: the solution builds successfully in Release mode on the CMS 12 and Commerce 14 target, and the CMS backend starts cleanly. 

Agent harness (execution layer)

Under the visible “agents and tools” sits an agent harness. This is not a model, it is the execution layer that makes agentic work safe and repeatable in real engineering environments. It provides: 

Skills Library 

This is an institutional memory. It contains validated patterns in categories such as migration patterns, CMS and Commerce patterns, DI and configuration patterns, and integration client patterns. Patterns move through a lifecycle: observed, validated, then automation safe. 

Specialist Subagents 

These are narrow, purpose-built agents invoked by the orchestrator: 

Toolchain Integrations

Agents do not work in abstraction. They execute real tooling such as dotnet build, dependency scanning, test runners, and report generation. Outputs are logged and attached to the run report. 

Main Agent

The orchestrator plans and drives the run, assigns work, tracks state and progress logs, enforces guardrails, and compiles the final report for developers and stakeholders. 

Build-Fix Loop

This is the heartbeat. Build output is classified against a migration debt index, fixes are dispatched, reviewer gating is applied, checkpoint commits are created, and the loop repeats until the debt index is empty. Only then does the workflow promote to Release build verification. 

A run moves through phases with explicit exit conditions and artifacts. 

Phase 1: Pre-flight and isolation

The orchestrator assesses solution structure, dependencies, and likely breaking zones. Work runs in an isolated branch. Baselines remain untouched. Every phase produces checkpoints, so a run is auditable and resumable. 

Phase 2: Guided migration

The machine applies upgrade transformations that convert known legacy patterns into modern equivalents and aligns dependencies for the target platform. This phase is migration-first: correctness of the target platform shape is prioritized over superficial compilation success. 

Phase 3: Continuous validation loop (the heartbeat)

This is where agentic AI earns its value. 

Phase 4: Release build verification and CMS boot validation

A Debug build is not enough. Release-mode build and CMS startup validation surface wiring issues that otherwise appear late. The pipeline repeats until Release build is clean and CMS backend starts cleanly. 

Phase 5: Output artifacts

At completion, the machine produces: 

The skills library is the single most important asset in the system and the reason results improve across engagements. A skill is a documented pattern with: 

Skills are not born autonomous. Patterns are captured from real engagements, validated across multiple independent codebases, and only then promoted to automation-safe. This prevents guesswork and reduces hidden regressions. 

Representative categories include: 

Agentic systems must be able to pause. Ours is designed to escalate. 

When the orchestrator hits an uncertainty threshold, it stops and asks for input. It proposes options and tradeoffs, then proceeds only after a decision is confirmed. 

Guardrails ensure changes remain safe and auditable: 

For engineering leaders, the risk profile is familiar: a disciplined internal branch-based workflow, just faster. 

We are deliberate about boundaries. 

Done for Part 1 (fully autonomous agentic workflow) means: 

What the delivery team does next (typically 2 to 6 weeks) 

This split keeps the model trustworthy. The machine accelerates engineering foundation work. The delivery team owns production readiness. 

Figure: From pipeline start to clean backend build in 4h 38m
 

Most teams plan a two-step journey, and we structure machine runs around that shape. 

Step 1 (this post): CMS 11 and Commerce 13 → CMS 12 and Commerce 14

This is the largest lift. The machine concentrates effort here because this is where repetitive refactoring and modernization posture work dominate. 

Step 2 (coming soon): CMS 12 and Commerce 14 → CMS 13 and Commerce 15

Once the platform is modernized, the next uplift is typically narrower and faster. Part 2 will cover how we apply the same workflow with a tighter skill set, and how we separate platform uplift from adoption of new capabilities. 

Every engagement produces a consistent artifact set: 

Is this a product or a delivery accelerator? 
A delivery accelerator used by Niteco engineers inside client engagements. 

Does it replace developer work? 
No. It reduces to minimal all repetitive refactors and compile-fix cycles. Engineers retain ownership of correctness and production readiness. 

Does it handle integrations and testing automatically? 
It accelerates code modernization and structured validation. Full integration certification and business acceptance remain delivery responsibilities. 

How do you keep changes safe and auditable? 
PR-style workflow, action logs, checkpoint commits, controlled escalation, and mandatory human review. 

Part 2 of this series will be published very soon.