I spent last week with seasoned Pega practitioners in Kolkata and Bangalore — the kind of forum where the questions are sharp because the deployments are real. One pattern surfaced repeatedly in the conversations and I want to bring it to this circle because it sits directly adjacent to two threads of work already active here.
Ivan’s recent posts — Modernization with Blueprint on Pega-as-a-Service and From Blueprint to Agents: How Pega GenAI Is Reshaping the Way We Deliver — make the case that the path from existing applications to modernized, agent-enabled applications runs through Blueprint as the design environment and Infinity Studio as the authoring environment, with Pega GenAI composed in along the way. The pending Infinity '26.1 release deepens this further with AI-assisted development inside the platform, and the MCP server and agent skills shipping in the same release surface Pega’s development and runtime tools to coding agents (Claude Code, GitHub Copilot, Codex) and work agents (Cowork, Copilot). Agentic development is no longer a future mode for Pega applications — it is the working reality the platform is positioning itself to support natively. The architects in India were asking a complementary question to what these capabilities enable. What happens to the legacy Pega applications that the customer is not ready to migrate, even with Blueprint and Infinity Studio accelerating the modernization work, and even with the new agentic capabilities making the case more compelling? The active thread Pega Chat Bot with AI conversation points at the same question from a different angle. The original poster is asking how to compose a GenAI agent with an existing Pega chat application that the customer already runs in production.
The pattern I want to surface. Treat the legacy Pega application the same way we would treat any other legacy asset that resists rewrite. Build a modern Pega application alongside the older one. Use the do-API to reach into the older application for data and existing functionality. Pull new functionality into the modern application as it becomes valuable to move. Let the older application continue serving as a system of record and as an active home for the user behavior it already supports well. Over time, the modern application absorbs the high-impact functionality, and the older application gracefully shrinks rather than being forced into a disruptive migration the institution cannot afford.
This is the wrap-and-replace pattern applied to Pega itself — a discipline many of us have used for years when working with non-Pega legacy assets. The question I want to put to this circle is whether we should be applying the same discipline to our own legacy Pega applications in the Pega-as-a-Service context, and whether the operational realities of running parallel applications in the managed-cloud environment shape how the pattern actually works.
Where this composes with the modernization work Ivan has been describing. Blueprint accelerates the design of the modern Pega application. Infinity Studio is where the authoring happens, with Infinity '26.1 bringing AI-assisted development inside the platform. The MCP server and agent skills extend that authoring surface to coding agents working in external environments (Claude Code, GitHub Copilot, Codex), and extend Pega’s runtime surface to work agents operating on cases inside applications (Cowork, Copilot). Together these address the design, authoring, and agent-accessibility problems at the modernization end. Wrap-and-replace addresses the migration sequencing problem at the other end — how the customer deploys the modern application into production alongside the legacy application that the modern one is conceptually replacing, with the do-API bridging the two and letting customers move functionality and users at the pace the institution can absorb. The patterns are complementary across the lifecycle. Design and authoring happen through Blueprint, Infinity Studio, and the agent-native development capabilities arriving with '26.1. Production sequencing happens through wrap-and-replace.
The variant that matters most for this circle: on-prem legacy moving to Pega-as-a-Service. The pattern’s hardest and most relevant variant is the customer whose legacy Pega application is running on-premises and whose modernized application has to run on Pega Cloud — because Pega-as-a-Service is the target deployment model. The two applications coexist across an environment boundary for the duration of the transition. The legacy on-prem application continues to run, the modern cloud application is built and deployed alongside it, and the do-API bridges them across the network boundary that separates the two environments. This is more operationally involved than coexistence within a single Pega Cloud tenant — it requires careful design of identity propagation, network connectivity, audit trail composition, and the operational handover between two environments that the customer and Pega Cloud are jointly operating during the transition. But it is the variant most customers carrying significant Pega debt actually face when they move to Pega-as-a-Service, and it is the variant that lets them move to the cloud at all rather than waiting for a single big-bang migration that the institution cannot absorb.
The retirement clock is real and the cadence is the discipline that addresses it. On-prem Pega applications running on older platform versions face a real support timeline. Customers who treat the legacy as permanent are accumulating risk that compounds the longer they wait. Wrap-and-replace only works as a migration pattern, not as a permanent state. The customer needs to plan the migration of capabilities from the legacy application into the modern application on a predictable cadence — a small number of functions per quarter, a defined retirement target for the legacy environment, a clear measure of progress toward emptying the legacy application of the work that justifies keeping it running. With that discipline, the legacy on-prem environment retires before it runs out of Pega support. Without it, wrap-and-replace becomes perpetual deferral, and the customer is back in the position the pattern was supposed to help them escape.
For the chat-with-GenAI use case specifically — which appears to be what the Pega Chat Bot with AI conversation thread is reaching for — wrap-and-replace would let the practitioner design the modern chat application in Blueprint, author it in Infinity Studio (with AI-assisted development from '26.1 accelerating the work where appropriate, or through a coding agent connected via the MCP server for teams that prefer to author in their existing development environment), and integrate the GenAI chat capability natively. The legacy chat application continues to handle the interactions it already handles well. New customer interactions can be routed to the modern chat where the GenAI capability is composed cleanly. Existing interactions can remain in the legacy chat. Over time, the modern chat absorbs the broader interaction patterns, and the legacy chat gracefully shrinks.
What I want from this circle. This pattern is not, as far as I know, an officially advocated Pega-as-a-Service adoption strategy. I am surfacing it because it came out of substantial practitioner conversations and it appears to address a real customer problem that the standard migration playbook does not.
Three questions I would value the circle’s input on, with the cloud operational context specifically in mind.
Have any of you applied this pattern in Pega-as-a-Service customer engagements? What worked in the cloud context, and what surfaced as a constraint that did not exist on-premises?
Are there architectural considerations specific to running parallel applications in the managed-cloud environment that would shape how the pattern is implemented — case dependencies across applications, identity propagation across the two applications, audit trail composition, the impact of release cycles when one application is on a current platform version and the other is on an older one?
If the pattern has merit for cloud customers, what would it take to make it a recommended Pega-as-a-Service modernization strategy — sitting alongside Blueprint for design, Infinity Studio and the agent-native development capabilities arriving with '26.1 for authoring, the MCP server and agent skills for coding-agent and work-agent integration, and Pega GenAI and the broader agentic stack for the composed capability — with reference architecture and tooling support for production deployment, rather than something individual partners and practitioners discover independently?
I have written about the broader architectural framing for adoption — including this pattern in less Pega-specific language, for an audience that includes non-Pega architects and technology leaders — on LinkedIn: The Architectural Reality of Agentic AI: Why Sequencing is Strategy. The version here is sharper, more Pega-as-a-Service specific, and grounded in the conversations practitioners on this circle are already having.
Looking forward to what the circle thinks.
-– Pumulo