Blog posts by Hung Le Hoang

Blog posts by Hung Le Hoang2026-05-18T02:51:52.0000000Zhttps://world.optimizely.com/blogs/hung-le-hoang/ Optimizely World Accelerating Optimizely CMS and Commerce upgrades with agentic AI (Part 2 of 2)The Real Transformation in Optimizely CMS 13: Why the Upgrade Itself Is the Easy Part. A field-tested playbook for enterprise teams moving from Optimizely CMS 12 and Commerce 14 to CMS 13 and Commerce 15. <a href="https://niteco.com/">Niteco</a> Engineering | Engineering Insights | 10 min read  <h2 class="MsoNormal">Series note</h2> This is Part 2 of a 2-part series on accelerating Optimizely upgrades with agentic AI. <ul style="margin-top: 0in;"> <li class="MsoNormal" style="mso-list: l2 level1 lfo1; tab-stops: list .5in;"><a href="/link/7b4736474f694aea8085db765bf46f9c.aspx">Part 1 : CMS 11 and Commerce 13 → CMS 12 and Commerce 14</a></li> <li class="MsoNormal" style="mso-list: l2 level1 lfo1; tab-stops: list .5in;">Part 2 (this post): CMS 12 and Commerce 14 → CMS 13 and Commerce 15, plus the adoption work that creates real business value</li> </ul> <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>TL;DR</h2> Completing the upgrade from Optimizely CMS 12 → CMS 13 and Commerce 14 → Commerce 15 is only the first step. By 2026 standards the upgrade itself is a solvable engineering exercise patterns are known, breaking changes are catalogued, and we have encoded the entire upgrade workflow into specialized AI Agent Skills that perform automated codebase analysis and large-scale modernization at speed and scale, operationalized on either advanced or open-source AI models. The real objective is something larger: aligning the solution with Optimizely’s long-term product roadmap. That means evolving the content model from PageData / BlockData to ExperienceData / Experience Pages, embracing Visual Builder, Optimizely Graph, Content Manager, the enhanced DAM, and Opal AI, and putting in place the foundations that let an organization move workloads between PaaS and SaaS without rewriting the frontend. The proposed direction strongly aligns with the recommended long-term architecture of CMS 13. This article describes the framework that delivers it, the accelerators that automate it, and the lessons from delivering it on a real enterprise PaaS estate. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>1. Two upgrades, one architectural destination</h2> Most enterprises arrive at CMS 13 with two parallel upgrade tracks running: <table class="Table" style="border-collapse: collapse; mso-table-layout-alt: fixed; mso-yfti-tbllook: 32; mso-padding-alt: 0in 5.4pt 0in 5.4pt; mso-border-insideh: .5pt solid windowtext;"> <thead> <tr style="mso-yfti-irow: -1; mso-yfti-firstrow: yes; mso-yfti-lastfirstrow: yes;"> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Track</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">From</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">To</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Nature</td> </tr> </thead> <tbody> <tr style="mso-yfti-irow: 0;"> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Content</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Optimizely CMS 12</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Optimizely CMS 13</td> <td style="width: 99.0pt; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">.NET 10, Graph-first, Visual Builder, decoupled identity, Content Manager, enhanced DAM, Opal</td> </tr> <tr style="mso-yfti-irow: 1; mso-yfti-lastrow: yes;"> <td style="width: 99.0pt; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Commerce</td> <td style="width: 99.0pt; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Optimizely Commerce 14</td> <td style="width: 99.0pt; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Optimizely Commerce 15</td> <td style="width: 99.0pt; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;">Aligned to the same CMS 13 / .NET 10 baseline: renewed catalog and order APIs</td> </tr> </tbody> </table>   Both tracks converge on the same architectural philosophy: a SaaS-grade authoring experience delivered on top of PaaS, with content delivered through Optimizely Graph, an AI-assisted editorial layer (Content Manager, Opal, enhanced DAM), and a clean separation between editor-owned layout and developer-owned components. Treating the CMS and Commerce upgrades as separate technical tasks may get you onto the latest platform versions, but it often leaves the solution operating with legacy CMS 12 design patterns, workflows, and content models. In that scenario, the technology is upgraded, but the business value remains limited. The real return on investment comes when both upgrade streams are aligned to a shared future-state architecture one that embraces Graph-first delivery, Visual Builder, modern editorial experiences, AI-assisted operations, and a clear separation between editor-managed layouts and developer-managed components, consistent with the direction of Optimizely’s long-term product roadmap. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>2. The technical upgrade is the easy part and we have automated it</h2> A standard CMS 12 → CMS 13 / Commerce 14 → Commerce 15 upgrade is a sequence of well-defined steps: 1.      Pre-upgrade analysis. Inventory .csproj files, EPiServer.* / Optimizely.* package references, deprecated API usage, and third-party add-on compatibility. 2.      Project file & dependency upgrade. Move every project to .NET 10, align every CMS-aligned package to the same 13.x.y release (we use 13.0.2 as the reference baseline), and remove deprecated packages such as EPiServer.Find.*. 3.      API migration. Mechanical replacements (PageReference → ContentReference, .PageLink → .ContentLink, IContentTypeRepository<T> → IContentTypeRepository, [Searchable(false)] → [IndexingType(IndexingType.Disabled)], SaveAction.Non → SaveAction.Default, ValidateArgNotNull → ArgumentNullException.ThrowIfNull) and structural ones (SiteDefinition.Current → IApplicationResolver / ISiteDefinitionResolver, ServiceLocator.Current → constructor injection, IPageRouteHelper → IContentRouteHelper). 4.      Scheduled job attribute alignment. [ScheduledPlugIn] → [ScheduledJob], drop the now-invalid SortIndex argument, and avoid the runtime CustomAttributeFormatException it otherwise produces. 5.      Custom property migration. Spaced DisplayName values on [PropertyDefinitionTypePlugIn] are rejected by CMS 13’s stricter name validation programmatic name must be a valid identifier; UI text moves to [Display]. 6.      Integration remediation. EPiServer.Find is removed entirely, surfaced as // TODO: [CMS13-MIGRATION] markers at every former call site, and migrated to Optimizely Graph (see more in §9) <span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">. 7.      Forms compatibility. EPiServer.Forms 5.10.x → 6.0.0, the CMS 13–compatible line. 8.      Startup / DI registration alignment. AddCms().AddContentGraph().AddContentManager() in the right order, plus AddCmsAspNetIdentity<ApplicationUser>() and AddVisitorGroups(). 9.      First-boot footguns. The trio that bites every project on day one of CMS 13: o   BlueprintInitialization failing because legacy SysRoot was set to Availability.Specific. o   PropertyDefinitionTypeInitialization failing on programmatic names that contain spaces. o   MissingMethodException on ContentReference.get_StartPage() when an add-on still ships CMS 12 binaries (the SiteImprove plugin and several Geta packages are typical culprits). We have encoded all of this and the analogous Commerce 14 → 15 workflow into specialized Agent Skills. They walk through an entire solution, produce a pre-upgrade report, apply safe transformations automatically, insert review markers where human judgement is required, drive dotnet restore / dotnet build to a clean state, and emit a structured migration report. This collapses what was historically a four-to-six-week engineer-led upgrade into hours of supervised automation. The honest framing for executives: the technical upgrade is no longer the constraint. Speed, risk, and cost are now bounded by the things automation cannot do the content-model transformation, the editorial change management, and the third-party long tail. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>3. The fundamental shift: From PageData to ExperienceData</h2> The single biggest conceptual and design-modeling change in CMS 13 is the evolution from the traditional PageData model to the modern ExperienceData / Experience Pages model. This is not a cosmetic rename or a new editing screen. It is a fundamental shift in how digital experiences are structured, composed, and managed by moving from page-centric content architecture to a modular, experience-centric design system built from Elements, Sections, Rows, Columns, Blueprints, and reusable Styles. <img style="display: block; margin-left: auto; margin-right: auto;" src="/link/f12d20d4746c4398bc7610f7ec7ad2e9.aspx" alt="Visual Builder hierarchy" width="933" height="414" />Visual Builder hierarchy: Experience → Section → Row → Column → Element, with Blueprint and Style applied across levels The Visual Builder content hierarchy: an Experience contains Sections; each Section contains Rows; each Row contains Columns; each Column holds Elements. Blueprints save reusable layouts at the Experience or Section level; Styles are developer-defined visual options that can be applied at any level via the More (…) menu. <table class="Table" style="border-collapse: collapse; mso-table-layout-alt: fixed; mso-yfti-tbllook: 32; mso-padding-alt: 0in 5.4pt 0in 5.4pt; mso-border-insideh: .5pt solid windowtext;"> <thead> <tr style="mso-yfti-irow: -1; mso-yfti-firstrow: yes; mso-yfti-lastfirstrow: yes;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> CMS 12 (page-centric) </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> CMS 13 (experience-centric) </td> </tr> </thead> <tbody> <tr style="mso-yfti-irow: 0;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> PageData </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> ExperienceData / Experience Page </td> </tr> <tr style="mso-yfti-irow: 1;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> BlockData (composite, monolithic) </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Element (atomic) + Block (kept for behavior-rich, data-driven units) </td> </tr> <tr style="mso-yfti-irow: 2;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> ContentArea (free-form blocks on a page) </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Section → Row → Column → Element (a structured grid editors compose visually) </td> </tr> <tr style="mso-yfti-irow: 3;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Display options on blocks </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Styles (developer-defined named options applied at Section / Row / Column / Element level) </td> </tr> <tr style="mso-yfti-irow: 4;"> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Page templates duplicated by editors </td> <td style="width: 2.75in; border: none; border-bottom: solid windowtext 1.0pt; mso-border-top-alt: solid windowtext .5pt; mso-border-bottom-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Blueprints (saved layouts reused at Section or Experience level) </td> </tr> <tr style="mso-yfti-irow: 5; mso-yfti-lastrow: yes;"> <td style="width: 2.75in; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Hidden tree navigation only </td> <td style="width: 2.75in; border: none; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt;"> Outline panel synchronised with live preview </td> </tr> </tbody> </table> The shift redistributes authority across the organization: ·       Editors gain control of layout. They add, reorder, and style Sections, Rows, and Columns without a developer ticket. ·       Developers retain control of components. Elements, their fields, and their style options remain code-defined and code-reviewed. ·       The interface creates clear responsibilities. Editors can manage and update content using approved components, while developers control how components are built and maintained. This allows editors to create page layouts freely within defined guardrails, without changing core component design or code. This separation is the single biggest reason CMS 13 deserves the “SaaS-grade experience on PaaS” label. It is also the reason content-model transformation is hard: every block in your existing site is an implicit decision about who owns layout, and most of those decisions need to be re-made. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>4. The five capabilities that make the migration worth it</h2> CMS 13 introduces five capabilities that, together, justify the architectural cost of the transformation. Treat them as the target state, not as optional add-ons. <h3>4.1 Visual Builder</h3> A live-preview, Outline-driven editing surface that activates automatically for any content type inheriting from ExperienceData. Editors compose pages from Sections, Rows, Columns, and Elements; Styles and Blueprints make repeatable patterns trivial. Visual Builder replaces the legacy On-Page Editing (OPE) experience as CMS 13’s default editing surface the On Page Editing mode and the All-Properties form are consolidated into one Outline + Live Preview workspace for Experience Pages. Legacy PageData content continues to use the form-based editor until it is migrated. <h3>4.2 Optimizely Graph integration</h3> Graph is no longer an optional headless layer; in CMS 13 it is the primary content-delivery and indexing fabric. AddContentGraph() is part of the CMS bootstrap. Search, content federation, semantic queries, and headless delivery all travel over the same pipe the same one a SaaS instance uses. <h3>4.3 Content Manager</h3> A Graph-powered editorial experience that augments and in many workflows replaces the traditional page tree. AI-driven semantic search across multiple content sources turns “where did we say that” from a 10-minute hunt into a single query. Registered with AddContentManager() after AddContentGraph(). <h3>4.4 Enhanced DAM</h3> Embedded digital asset management with direct uploads, AI-powered tagging, automatic renditions, and saved views, all inside the CMS, replacing the older EPiServer.Cms.WelcomeIntegration.UI line. DAM adoption is itself an Agent Skill. We have encoded enhanced-DAM implementation patterns, package replacement, configuration, asset model mapping, rendition strategy, migration of legacy assets, and integration into Visual Builder Element fields into specialized Agent Skills. The AI agents accelerate DAM adoption, integration, asset mapping, and modernization tasks the same way it accelerates the platform upgrade itself. <h3>4.5 Opal AI integration</h3> Optimizely’s AI agent orchestration platform with pre-built agents and custom workflows, RAG-powered against your own content. The most leveraged use cases on day one are SEO assistance, content drafting, alt-text generation, editorial QA, and merchandising support on the Commerce side. These five capabilities are interlocking. Visual Builder needs Graph for preview; Content Manager needs Graph for search; Opal needs Content Manager and DAM for grounded, content-aware suggestions. Adopting them in isolation leaves value on the table. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>5. The Visual Builder adoption framework</h2> The framework below has been pressure-tested on a live CMS 12 → CMS 13 program. It is deliberately a five-phase plan that maps cleanly to budget cycles, editorial readiness, and release windows not a 20-step process that loses sponsorship within the first two months. <h3>Phase 1: Enable Visual Builder (Foundation + Pilot)</h3> Goal: Make Visual Builder live in the upgraded environment with one production-quality reference Experience Page; lock the cross-cutting decisions for the rest of the program. ·       Run the upgrade Agent Skill end-to-end in a sandbox copy of production. ·       Stand up the Visual Builder foundation (ExperienceData, SiteExperienceData, the Element library, the _RootExperience.cshtml layout) alongside the legacy templates the Niteco CMS 13 PaaS Foundation provides this turnkey. ·       Author one representative Experience Page end-to-end in Visual Builder typically a marketing landing page that exercises hero, image+text, CTA, and at least one behavior-rich block (e.g., Forms) used as a Block Element. This becomes the canonical reference for editorial training. ·       Validate header / footer parity, SEO meta, Open Graph, breadcrumb, hreflang, canonical, robots, GTM and 3rd-party scripts, language switching, preview, draft / publish, scheduled publish, and rollback. ·       Lock the cross-cutting decisions: hybrid Block / Element policy, cutover model (replace-in-place vs. alongside-then-swap), redirect store ownership, personalization parity strategy, Graph consumer ownership. Editor outcome: Editors use Visual Builder as the unified editing experience. Existing PageData content can be managed in the same interface, while advanced layout capabilities such as Sections, Rows, Columns, Elements, Blueprints, and reusable Styles are available for Experience Pages. <h3>Phase 2: Discovery & Transformation</h3> Goal: Produce a Decomposition Spec the single source of truth that drives both content modeling (Phase 3) and the AI Migration Accelerator (Phase 4). The Decomposition Spec is one document containing five tables, fully populated for the entire site: 1.      Page-type strategy: every legacy PageType mapped to a target Experience Page, kept classic, or scheduled for retirement. 2.      Block decomposition: every legacy block classified as decompose into Elements, keep as Block Element (Forms, Navigation, complex carousels, product lists), or retire. Includes the target Section/Row/Column shape and the display-option mapping. Example: ImageTextBlock → ImageElement + HeadingElement + ParagraphElement + CtaGroupElement arranged in a 2-column Row. 3.      Display option mapping: every legacy display option mapped to a Section / Row / Column / Element Style, or to a brand/theme variant. 4.      Personalization & A/B audit: every visitor-group rule and experiment classified as auto-migrate, manual rebuild or retire Personalization and A/B testing on CMS 13: A stronger foundation <span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">(see §7<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">). 5.      Graph consumer inventory: every external consumer of CMS content with the new query shape it requires (<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">see §10). <h3>Phase 3: Content modeling & Parity layer</h3> Goal: Make the Visual Builder content model production-ready and at parity with classic templates for all cross-cutting concerns. ·       Build the Element library by extending the Niteco CMS 13 Foundation, with Site-specific Elements added where required. Reuse the foundation’s semantic Tailwind architecture (primitives → brand → theme contract → components) for variants never fork the Element library per market. ·       Reach full parity between SitePageData and SiteExperienceData for SEO title and description, robots, canonical, hreflang, Open Graph, JSON-LD structured data, breadcrumb, language switcher metadata, and 3rd-party script slots. ·       Layout parity between _Root.cshtml and _RootExperience.cshtml for header, footer, and global scripts. Shared site fixtures (WebFooterConfigurationBlock, site settings) stay shared and are referenced by the layout they are never re-modeled per Experience Page. ·       Lock AvailableContentTypes at every level of the content hierarchy (Experience Pages allow only Sections; Sections allow only Rows; Rows allow only Columns; Columns allow only whitelisted Elements + Block Elements). This is what protects editor UX from chaos at scale. <h3>Phase 4: Content migration (powered by the AI Migration Accelerator)</h3> Goal: Migrate production content from PageData + ContentArea into Experience Pages at the pace your editors and traffic can absorb. The migration is executed by Niteco’s AI Migration Accelerator <a style="mso-comment-reference: BH_4; mso-comment-date: 20260515T1120;" href="">(</a><span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">§10), a migration engine driven by the Decomposition Spec. ·       Migrate by market / business unit / volume smallest, lowest-risk batches first. ·       Per-batch ritual: dry-run + diff report, editorial spot-check, DB snapshot, run, validate against the harness (visual diff, Lighthouse, SEO meta parity, sitemap parity, Graph parity, broken-link scan), editorial sign-off, promote. ·       Cutover model per page: prefer replace-in-place (delete legacy, take its URL) for SEO cleanliness; use alongside-then-swap (publish new alongside, swap with redirect at cutover) where rollback safety dominates. <h3>Phase 5: Cutover & Decommission</h3> Goal: Remove legacy surface area and close the program. ·       Mark legacy block & page types [Obsolete]; restrict via AvailableContentTypes to prevent any new editor usage. ·       Remove unused controllers, view models, view templates, and Display Templates. ·       Finalise sitemap.xml, hreflang, and robots.txt to reflect the final URL set; verify 301 coverage with a final crawl. ·       Deliver editorial training on the post-migration content model and the Visual Builder style guide. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>6. Hybrid rendering: The practical bridge, not a compromise</h2> A common objection from leadership: “Why can’t we just convert everything in one release?” Two reasons. First, multi-thousand-page estates cannot be migrated, validated, and editorially reviewed in a single window without unacceptable SEO and editorial risk. Second, CMS 13’s architecture expects coexistence, both PageData and ExperienceData are first-class citizens; Block Elements let behavior-rich blocks live inside Visual Builder Columns; both editing surfaces can run side-by-side for months. A healthy hybrid model looks like this: ·       Decompose layout-flexible composites (ImageTextBlock, HeroBannerBlock, EditorialBlock, CTAGroupBlock) into Elements arranged in Sections/Rows/Columns. ·       Keep as Block Elements the behavior-rich units: FormBlock, navigation menus, complex carousels with custom JS, product listings, search facets anything with non-trivial controller logic. ·       Keep shared the cross-cutting site fixtures: WebFooterConfigurationBlock, site settings, header / footer / global scripts. These live on shared content and are referenced by the layout. ·       Lock the contract with AvailableContentTypes, so editors compose only valid structures. The hybrid model is the bridge. Done well, it lets you migrate at the pace your business absorbs, not the pace your migration script can theoretically deliver and it allows gradual modernization without requiring a full rewrite replatform. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>7. Personalization and A/B testing on CMS 13: A stronger foundation</h2> Personalization and experimentation are usually the first capabilities a marketing team asks about post-upgrade and CMS 13 delivers a meaningfully better foundation for both, if the migration plan is built with them in mind. <h3>What changes</h3> ·       Personalization scope moves from blocks to Elements / Sections. In CMS 12, visitor groups were typically attached to ContentArea items. In CMS 13, the equivalent units are Elements and Sections finer-grained, more composable, and visible in the Visual Builder Outline. The blast radius of a personalization rule is now exactly what the editor can see in the preview. ·       Native content variations on Experience Pages. Editors can create and publish multiple named variants of the same page for A/B testing, personalization, campaigns, or localization in Visual Builder, each with its own lifecycle. Optimizely Graph queries should explicitly use the variation field when variant delivery is needed. ·       Graph becomes the personalization data layer. With AddContentGraph() in the bootstrap, audience attributes, segments, and content metadata are queryable from a single API. Real-time decisioning that previously required custom plumbing now sits naturally on top of Graph. ·       Experimentation aligns with Web Experimentation. Optimizely Web Experimentation runs cleanly against Experience Pages, with a much richer test surface (Section-level variants, Element-level swaps, Style toggles) than the page-template-or-bust split-tests common on CMS 12. ·       Opal closes the loop. Opal agents can propose audience segments, suggest variant content, and analyse experiment outcomes against your own content corpus, turning experimentation from an ops task into an editorial workflow. <h3>What this means for the migration plan</h3> ·       Audit personalization in Phase 2. Every visitor-group rule and active experiment goes into Decomposition Spec table 4 (<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">§3). Each one is classified as auto-migrate, manual rebuild or retire. ·       Pick the right level of granularity. A personalization rule that used to swap a whole ContentArea block can now be expressed as either a Section variant, a Style toggle, or an Element-level swap. The Decomposition Spec records the chosen granularity per rule. ·       Set the experimentation baseline before cutover. Capture conversion baselines on legacy templates before migration so post-migration experiments have a credible reference. Graph parity in the validation harness <span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">(<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">§10<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">) ensures the data layer behaves identically across the cutover. ·       Train the editors, not just the developers. The marketing win from CMS 13 is not “we can A/B test ”they could already do that. It is “we can A/B test inside the same surface where we author.” Editorial enablement decides whether that win is realised. The strategic frame: Personalization and A/B testing on CMS 12 were typically bolted on wired through visitor groups, custom controllers, and a separate experimentation tool. On CMS 13 they are native composable inside Visual Builder, queryable through Graph, and orchestrated by Opal. The migration plan should treat this as a primary business case for the program, not a Phase 6 afterthought. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>8. The PaaS Foundation: One frontend, two runtimes</h2> One of the highest-leverage investments we have made on the PaaS side is a CMS 13 Foundation accelerator that supports four delivery modes from a single codebase: ·       Headless hosting: Graph-driven content delivery to an external frontend. ·       In-process rendering: classic ASP.NET Core MVC + Razor for templates, including the _RootExperience.cshtml layout and Display Templates for every Element. ·       SaaS compatibility: content models, queries, and frontend conventions that are valid on both PaaS and SaaS. ·       Shared frontend architecture: a single component library, design-token system, and Tailwind theme contract used by both the in-process Razor templates and the headless frontend. The strategic insight: when PaaS runs in headless mode, content is delivered through Graph exactly the same way SaaS delivers it. The frontend cannot tell the difference. This collapses the future cost of a SaaS migration from “replatform project” to “DNS cutover and a content sync.” Concretely, an organization on the Foundation can: 1.      Start on PaaS in-process for low-risk migration off CMS 12. 2.      Move selected experiences (or selected markets) to headless without changing the content model. 3.      Eventually migrate to SaaS without rewriting the frontend. It is the cheapest insurance an enterprise can buy against Optimizely’s ongoing SaaS roadmap, and it removes the replatform fear that typically blocks SaaS conversations entirely. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>9. From Find to Graph: Automated by Agent Skills</h2> EPiServer.Find is removed in CMS 13. There is no drop-in replacement; Optimizely Graph is the strategic destination for search, indexing, and content federation. If being done by hand, this is the single largest source of unscoped effort in a CMS 13 program. In Niteco, we have encoded the migration into Find → Graph Agent Skills. They have been trained and optimized on real Find implementations and produce Graph-ready architectures with mapped schemas, translated queries, rewritten integration logic, and explicit human-review markers where business judgement is required. Concretely, the Agent Skills: ·       Inventory every Find usage in the solution: IClient, SearchClient.Instance, Find() query DSL, For<T>() projections, custom conventions, indexing pipelines, boost profiles, and synonyms. ·       Map indexed content models to Graph schemas, surfacing fields that need new indexers or computed properties. ·       Translate query patterns: filters, facets, term queries, and free-text search into equivalent Graph queries (OR/AND filter trees, faceted aggregations, _Fulltext searches). ·       Rewrite integration logic search controllers, autosuggest endpoints, content listing components. ·       Insert // TODO: [CMS13-MIGRATION] markers wherever human judgement is required (e.g., custom relevance tuning, multi-index queries with no clean Graph equivalent). The key point: the Agent Skills do not eliminate human review relevance tuning is intrinsically content-and-business-specific. They eliminate the mechanical 80%-90% that historically dominated the migration calendar, significantly accelerating timelines while reducing manual effort, technical risk, and reimplementation cost. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>10. The AI Migration Accelerator: Niteco’s content migration tooling</h2> The hardest unsolved problem in a CMS 13 program is content migration: how to take thousands of legacy pages composed of PageData + ContentArea + Block and turn them into well-formed Experience Pages without losing URLs, language branches, versions, ACLs, personalization rules, scheduled publishes, or cross-references. Niteco has developed a set of AI Migration Accelerators to solve exactly this. The architecture is deliberate: ·       AI agents driven by the Decomposition Spec. The Decomposition Spec from Phase 2 is executable input same input, same output, every run. Determinism is non-negotiable for a migration that must be re-runnable, diffable, and rollback-able. ·       Further AI assistance in narrowly scoped sub-modules. Each AI sub-module is isolated and reviewable: a RichText splitter that proposes heading/paragraph chunking, an alt-text suggester for images that lack alt, a background-variant ranker that proposes Section Style choices. Humans approve; AI proposes. ·       Identity preservation by default. Every legacy ContentReference is mapped to a new ContentReference, persisted in an identity map, and used to rewrite cross-references in ContentReference, ContentArea, LinkItemCollection, and RichText fragments on other pages. ·       Full preservation contract. URLs (with auto-generated 301s for moves), all language branches, draft + published versions, ACLs, categories, scheduled publish/expire, personalization rules, A/B test attachments, and EPiServer.Forms instance identity. ·       Validation harness as a hard gate. Per-batch automated gates on visual diff, Lighthouse parity, SEO meta parity, sitemap parity, Graph query parity, and a broken-link scan. A batch promotes only when every gate is green. ·       Per-batch rollback. DB snapshot + content export before each batch, with a defined rollback SLA. The key point: the AI Migration Accelerator turns content migration from a bespoke heroic project into a repeatable, auditable, batch-safe workflow the only realistic way to migrate a multi-thousand-page enterprise estate inside a sensible release window. Combined with the upgrade Agent Skills (<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">§2) and the Find → Graph Agent Skills (<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">§9), the AI Migration Accelerator completes the automation story end-to-end: upgrade, search migration, and content migration are all driven by AI Agents. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>11. The third-party reality check</h2> Most enterprise CMS 12 estates carry a long tail of community and vendor add-ons. CMS 13 breaks many of them, sometimes silently. The official <a href="https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/optimizely-third-party-packages-breaking-changes">Optimizely third-party packages breaking changes</a> page is mandatory reading; the practical pattern we recommend is: <table class="Table" style="border-collapse: collapse; width: 53.8283%; height: 459.406px;"> <thead> <tr style="height: 47.6562px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 47.6562px;"> Pattern </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 47.6562px;"> Implication </td> </tr> </thead> <tbody> <tr style="height: 48.6562px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 48.6562px;"> NU1202 on .NET 10.0 </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 48.6562px;"> Package not built for net10.0. Upgrade or remove. </td> </tr> <tr style="height: 107.625px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 107.625px;"> NU1608 with upper bound < 13.0.0 on EPiServer.* / Optimizely.* </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 107.625px;"> Add-on is shipping CMS 12 binaries. Restore may succeed; runtime will throw MissingMethodException / TypeLoadException. Treat as a release blocker, not a warning. </td> </tr> <tr style="height: 88.9688px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 88.9688px;"> Add-on capped against CMS 12 with no CMS 13 build (e.g., SiteImprove.Optimizely.Plugin, several Geta packages, Advanced.CMS.AdvancedReviews) </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 88.9688px;"> Remove for now; re-add when a CMS 13 build ships. </td> </tr> <tr style="height: 48.5938px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 48.5938px;"> EPiServer.Forms 5.10.x </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 48.5938px;"> Upgrade to 6.0.0. </td> </tr> <tr style="height: 69.3125px;"> <td style="width: 52.3297%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 69.3125px;"> EPiServer.Cms.WelcomeIntegration.UI </td> <td style="width: 47.6703%; border-width: medium medium 1pt; border-style: none none solid; border-color: currentcolor currentcolor windowtext; border-image: initial; padding: 0in 5.4pt; height: 69.3125px;"> Replace with EPiServer.Cms.DamIntegration.UI; remove the legacy AddDAMUi(). </td> </tr> <tr style="height: 48.5938px;"> <td style="width: 52.3297%; padding: 0in 5.4pt; border-image: initial; height: 48.5938px; border: medium none currentcolor;"> EPiServer.Find.* </td> <td style="width: 47.6703%; padding: 0in 5.4pt; border-image: initial; height: 48.5938px; border: medium none currentcolor;"> Remove entirely; migrate to Graph (<span style="background-image: initial; background-position: initial; background-size: initial; background-repeat: initial; background-attachment: initial; background-origin: initial; background-clip: initial;">see §9). </td> </tr> </tbody> </table> The two non-obvious traps that account for most go-live incidents: 1.      NU1608 ignored at restore. A CMS 12 binary loaded into a CMS 13 process will compile and run for many seconds before the first content event triggers the MissingMethodException. Hard-fail the build on NU1608 across EPiServer.* and Optimizely.*. 2.      SysRoot availability. Legacy databases often have SysRoot set to Availability.Specific, which blocks CMS 13’s BlueprintInitialization from creating SysContentFolder on first boot. The fix is a one-time SQL operation; the prerequisite is to know it’s coming before your first deployment window. The upgrade Agent Skill scans for both of these in Phase 1 of the analysis and flags them in the pre-upgrade report turning what used to be go-live surprises into planning inputs. <div class="MsoNormal" style="text-align: center;" align="center"><hr /></div> <h2>12. What good looks like at the end</h2> A CMS 13 program executed against this framework lands with the following properties: ·       Editor experience. Marketing teams compose, preview, and publish pages in Visual Builder without developer involvement, using a code-defined Element library and pre-approved Styles. Blueprints turn repeatable patterns into one-click starts. Personalization and A/B testing live inside the same surface where authors compose. ·       Architecture. A Graph-driven content layer is the single source of truth for delivery, search, and federation. Content Manager is the editorial home; Opal grounds AI assistance against your own content; the enhanced DAM is the asset of record. ·       Frontend. One component library, one design-token system, one Tailwind theme contract. The same frontend renders in-process Razor on PaaS and via Graph on headless or SaaS. ·       Operations. Upgrades are automated by Agent Skills; third-party add-ons are evaluated against a hard-fail NU1608 gate; Find-based search is gone, replaced by Graph; every page that moved during migration is covered by a 301 in the redirect store. ·       Strategic posture. The organization is ready to move workloads to SaaS without a frontend rewrite when (and only when) the business case is right. The technical upgrade gets you to CMS 13 running. The content-model transformation, executed against this framework with Niteco’s Agent Skills and AI Migration Accelerators, gets you to CMS 13 delivering value and strongly aligned with the recommended long-term architecture of CMS 13. They are different programs, on different timelines, with different success criteria. Conflating them is the root cause of most underwhelming CMS 13 launches we have seen. Separating them is the root cause of most successful ones. <hr /> <h2 class="MsoBlockText" style="margin-left: 0in;"><span style="font-size: 16.0pt; font-family: 'Aptos Display',sans-serif; mso-ascii-theme-font: major-latin; mso-fareast-font-family: 'Times New Roman'; mso-fareast-theme-font: major-fareast; mso-hansi-theme-font: major-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: major-bidi; color: #0f4761; mso-themecolor: accent1; mso-themeshade: 191; mso-fareast-language: EN-US;">Closing </h2> If you are planning the step from CMS 12 and Commerce 14 to CMS 13 and Commerce 15, treat it as two tracks: platform uplift and capability adoption. The first is solvable. The second is where the value is. At Niteco, our agentic AI Upgrade Machine accelerates the repetitive engineering work and produces auditable outputs that delivery teams can stabilize and ship with confidence. Learn more at <a href="https://niteco.com/">https://niteco.com/</a> or contact <a href="https://niteco.com/contact-us/">https://niteco.com/contact-us/</a> and reference “Upgrade Machine”.2026-05-18T02:51:52.0000000Z

Blog post

Accelerating Optimizely CMS and Commerce upgrades with agentic AI (Part 1 of 2)<div class="SCXW16943011 BCX0"> <div class="OutlineElement Ltr SCXW16943011 BCX0"> <a href="https://niteco.com/our-partners/optimizely/upgrade/">Niteco's Upgrade Machine</a> uses orchestrated AI coding agents to create a buildable starting point and a working CMS. After that, the process is handed over for stabilization and deployment. <a href="https://niteco.com/">Niteco</a> Engineering | Engineering Insights | 10 min read <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">Blog series </h2> This is Part 1 of a 2-part series on accelerating Optimizely upgrades with agentic AI. ·    Part 1 (this post): CMS 11 and Commerce 13 → CMS 12 and Commerce 14 ·    <a href="/link/f0835bcd10f145efa161d583304274fa.aspx">Part 2: CMS 12 and Commerce 14 → CMS 13 and Commerce 15, and how we scope platform uplift vs capability adoption</a> </div> <div class="ListContainerWrapper SCXW16943011 BCX0"> <img src="/link/3197918e99394bbaa3068769c8efe1b8.aspx?1778486868721" alt="Niteco Agentic Upgrade Machine (CMS 11 and Commerce 13 → CMS 12 and Commerce 14)" width="1398" height="654" /> Image: Niteco agentic Upgrade Machine (CMS 11 and Commerce 13 → CMS 12 and Commerce 14)  </div> <div class="OutlineElement Ltr SCXW16943011 BCX0"> </div> <div class="ListContainerWrapper SCXW16943011 BCX0"> TL;DR We created the Upgrade Machine, an AI system with a main orchestrator, specialized subagents, and a growing skills library. It speeds up the most repetitive part of an Optimizely upgrade by producing a PR-ready codebase that builds in Release mode and starts the CMS backend cleanly on the target platform. After that, a Niteco delivery team steps in to stabilize integrations, verify behavior, and move the project to production. This usually takes 2 to 6 weeks, depending on the project's size. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">1. Why Optimizely upgrades stall (and why timing matters now)</h2> Upgrading Optimizely is more than just updating a package. It affects runtime assumptions, custom code, integrations, routing, dependency injection, configuration, content models, and readiness for cutover. Moving from CMS 11 and Commerce 13 to CMS 12 and Commerce 14 is a big change because it is part of a larger platform update. Stable patterns may suddenly need major changes. There is also a lifecycle reality. <a href="https://support.optimizely.com/hc/en-us/articles/30886353301645-2025-2026-Optimizely-CMS-11-release-notes#CMSversionpolicy">Optimizely’s policy</a> is that all new functionality is built only for the latest major CMS version (currently CMS 13). Optimizely actively monitors and fixes severe bugs and security issues only for the current major version and one prior major version  (currently CMS 13 and CMS 12). Older versions such as CMS 11 do not receive ongoing bug monitoring, standard bug fixes, security monitoring, or regular patch releases, except in exceptional cases involving severe security vulnerabilities raised by customers/partners. Practically, delaying the upgrade increases platform and security risk because you’re operating outside the normal maintenance and patch cadence. From our experience, the biggest delays come from discovery gaps like undocumented integrations, old helper code, and tricky configuration wiring. These issues slow teams down with repeated compile-fix cycles and unexpected problems late in the process. Our goal with the Upgrade Machine is simple: take the repetitive refactoring out of the main workflow and give engineers a clean, buildable starting point. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">2. What automation solves, and where it stops </h2> 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. Problems arise when upgrades involve complex work, such as changes across files, unclear intent, or cases where several fixes might work but only one fits the platform's needs. Rule engines can't understand intent- they either make a safe change or escalate the issue. These escalations often pile up, creating a manual backlog that can last for weeks. This is where agentic AI makes a real difference. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">3. The agentic approach: what we built (part 1 focus) </h2> The Upgrade Machine is a coordinated system of AI coding agents working within a managed workflow. ·    A main agent orchestrates the run: it sequences phases, enforces quality gates, and tracks progress in a persistent log. ·    Specialist subagents handle narrow domains: code fixes, reviewer checks, unit-test scaffolding, and skill enrichment. ·    A shared skills library encodes typical upgrade patterns derived from real delivery work. Each skill has clear triggers, a defined transformation approach, and validation rules. Two design choices matter most. First, agents have autonomy but with clear limits. They can work on their own, but only within a process that includes checkpoints, reviewer checks, and escalation points. If the system is unsure, it stops and asks a developer to decide instead of making a guess. Second, the system gets better over time. Each project adds new patterns to the skills library. The system improves by capturing what works, testing it in different situations, and turning it into safe automation. For this post (part 1), we define 'done' as follows: the solution builds in Release mode on the CMS 12 and Commerce 14 targets, and the CMS backend starts without issues. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">4. Upgrade Machine, an agent harness architecture </h2> <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 7.0pt 0in 7.0pt 0in;">Agent harness (execution layer)</h3> Behind the visible agents and tools is the agent harness. This is not just a model - it is the part that makes agentic work safe and repeatable in real engineering settings. It provides: ·    Run isolation and reproducibility: creates an isolated workspace and enforces a checkpointed, branch-based flow so changes are easy to audit, pause, and resume. ·    State and context management: packages the minimum required context for each subagent, tracks progress state, and prevents uncontrolled context drift across long runs. ·    Tool governance: controls which tools an agent can use, in what sequence, and under what policy constraints (build, scan, test, report) so automation stays deterministic. ·    Quality gates and escalation: enforces reviewer gates and uncertainty thresholds, escalating to a human decision when intent is ambiguous or risk of behavior change is high. ·    Observability and artifacts: collects structured logs, code differences, and run outputs like reports, checklists, and lists of remaining decisions. This helps delivery teams stabilize and deploy with confidence. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Skills library </h3> This acts as the team's memory. It holds proven patterns in areas like migration, CMS and Commerce, dependency injection, configuration, and integration clients. Patterns go through a process: they are first observed, then validated, and finally marked as safe for automation. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Specialist subagents </h3> These are narrow, purpose-built agents invoked by the orchestrator: ·    Code-fix agent: applies migration fixes guided by the skills library ·    Reviewer agent: validates output against the skills library and rejects fixes that compile but violate migration intent ·    Unit-test agent: scaffolds and runs tests where feasible ·    Skill-enrichment agent: captures new patterns discovered during the run and feeds them back into the skills library <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Toolchain integrations</h3> Agents do not work in isolation. They use real tools like dotnet build, dependency scanners, test runners, and report generators. All outputs are logged and included in the run report. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Main agent</h3> 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. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Build-fix loop</h3> This is the core of the process. Build results are checked against a migration debt index, fixes are made, reviewer checks are done, and checkpoint commits are created. This loop continues until the debt index is cleared. Only then does the workflow move to Release build verification. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">5. How a run works end-to-end (CMS 11 and Commerce 13 → CMS 12 and Commerce 14) </h2> A run moves through phases with explicit exit conditions and artifacts. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Phase 1: pre-flight and isolation</h3> 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. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Phase 2: guided migration</h3> The machine upgrades legacy patterns to modern ones and updates dependencies for the target platform. In this phase, getting the target platform right is more important than just making the code compile. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Phase 3: continuous validation loop (the heartbeat)</h3> This is where agentic AI proves its worth. ·    The orchestrator builds and classifies issues against migration debt patterns. ·    Code-fix is dispatched in controlled batches. ·    A reviewer gate validates that fixes align with accepted patterns, not quick shims. ·    Checkpoints are committed only after reviewer acceptance. ·    If progress stalls or intent becomes ambiguous, the system escalates to a developer with options and rationale. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Phase 4: Release build verification and CMS boot validation</h3> A Debug build alone is not enough. Building in Release mode and checking CMS startup helps catch wiring issues early. The process repeats until the Release build is clean and the CMS backend starts without problems. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Phase 5: Output artifacts</h3> At completion, the machine produces: ·    PR-ready branch with checkpoint commits ·    Structured change log grouped by pattern families ·    Build logs and run summary ·    Remaining decisions list (items intentionally escalated to humans) ·    Stabilization checklist tailored to the solution footprint ·    Skill enrichment notes for future runs <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">6. Skills library: deep enough to trust, not detailed enough to copy </h2> The skills library is the most valuable part of the system and is why results get better over time. Each skill is a documented pattern with: ·    Trigger: how the system detects the pattern (error signature, code shape, dependency signal) ·    Transformation: how code is changed safely ·    Validation: how correctness is verified beyond “it compiles” Skills do not start out as automated. Patterns are collected from real projects, tested in different codebases, and only then marked as safe for automation. This approach avoids guesswork and helps prevent hidden problems. Representative categories include: ·    Project and dependency modernization patterns ·    DI and configuration patterns aligned to modern platform expectations ·    Routing and runtime initialization patterns ·    Integration client modernization patterns (safe client setup, resilience, async correctness) ·    Commerce-related upgrade patterns where the upgrade path diverges ·    Safe cleanup patterns that require explicit human sign-off <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">7. Human-in-the-loop and guardrails </h2> Agentic systems need to be able to pause. Our system is built to escalate issues when needed. When the orchestrator reaches a point of uncertainty, it stops and asks for input. It suggests options and tradeoffs, and only moves forward after a decision is made. Guardrails ensure changes remain safe and auditable: ·    PR-style diff flow ·    Checkpoint commits at every phase ·    Full action logs ·    Reproducible runs ·    Mandatory human review before merge ·    No deployment actions by the machine For engineering leaders, the risk profile is familiar. It is a disciplined, branch-based workflow, just much faster. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">8. Definition of done and the handover model (part 1) </h2> We are deliberate about boundaries. Done for Part 1 (fully autonomous agentic workflow) means: ·    The solution builds successfully in Release mode on the CMS 12 and Commerce 14 target ·    The CMS backend starts cleanly ·    Artifacts are produced: change log, build logs, remaining decisions list, stabilization checklist What the delivery team does next (typically 2 to 6 weeks) ·    Stabilize regressions surfaced by functional and exploratory testing ·    Validate integrations, scheduled jobs, and data flows ·    Address performance and security hardening as required ·    Prepare deployment, rehearse cutover, and ship to production This division keeps the model reliable. The machine speeds up the foundational engineering work, while the delivery team is responsible for making sure the solution is ready for production. </div> </div> <div class="SCXW16943011 BCX0"> <div class="OutlineElement Ltr SCXW16943011 BCX0"> <img src="/link/18285d797df044458357ccae170a7531.aspx" alt="From pipeline start to clean backend build in 4h 38m" width="1697" height="415" /> Image: from pipeline start to clean backend build in 4h 38m   </div> </div> <div class="SCXW16943011 BCX0"> <div class="OutlineElement Ltr SCXW16943011 BCX0"> <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">9. Mapping to the 2-step journey (and what comes next) </h2> Most teams plan a two-step journey, and we structure machine runs around that shape. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Step 1 (this post): CMS 11 and Commerce 13 → CMS 12 and Commerce 14</h3> This is the biggest step. The machine focuses its effort here because this phase involves the most repetitive refactoring and modernization work. <h3 style="mso-pagination: widow-orphan; page-break-after: auto; margin: 14.05pt 0in 7.0pt 0in;">Step 2 (coming soon): CMS 12 and Commerce 14 → CMS 13 and Commerce 15</h3> After the platform is modernized, the next upgrade is usually smaller and quicker. Part 2 will explain how we use the same workflow with a more focused skill set, and how we separate platform upgrades from adding new features. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">10. What you receive from a run </h2> Every engagement produces a consistent artifact set: ·    PR-ready upgraded branch ·    Structured change report grouped by patterns ·    Build logs and run summaries ·    Remaining decisions list ·    Stabilization checklist tailored to the solution footprint ·    Optional internal playbook updates (pattern learning, skill enrichment) <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">11. FAQ </h2> 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. <h2 style="mso-pagination: widow-orphan; page-break-after: auto; margin: .25in 0in 9.0pt 0in;">12. Closing and contact</h2> Optimizely upgrades do not have to be long, repetitive projects. Using agentic AI with discipline, clear guardrails, and a growing skills library is a practical way to speed up the foundation work and deliver value faster. If you are planning a CMS or Commerce upgrade and want to learn more, you can contact <a href="https://niteco.com/contact-us/">https://niteco.com/contact-us/ </a>and mention “Upgrade Machine”. Part 2 of this series can be found <a href="/link/f0835bcd10f145efa161d583304274fa.aspx">here</a>. </div> <div class="OutlineElement Ltr SCXW16943011 BCX0">   </div> </div>2026-05-11T07:50:54.0000000Z

Blog post