A notable development - Pegasystems taps into the Notes replacement market opportunity

Big companies bought a lot of licenses/seats for HCL Notes (née IBM Notes, itself née Lotus Notes) starting in the 1990s. Several big services firms (e.g., PriceWaterhouse, Accenture, etc.) were users of this tool which could handle email, document sharing, forms-based apps and more. My own team built a massive knowledge management tool re: ERP software in Lotus Notes.

Like many software products developed in the 1990s, these applications would eventually face some measure of obsolescence and require either redevelopment or replacement.  However, not all customers of a given software product can afford to make such a change especially if it is cost-prohibitive, time-consuming or otherwise infeasible to do so at a given time. Some old applications can be too sticky to users or other applications to change out. Whatever the reason, old apps accumulate a lot of technical debt and complicate a firm’s IT environment.

With regard to Notes, David Farquhar of The Silicon Underground wrote:

This is one reason Notes sticks around today even in shops that long since migrated to Exchange or something else for calendaring and e-mail. They have custom applications written in Notes that are business critical and may date back to the 1990s and whoever wrote them is probably long gone. Reimplementing these custom applications in something else is frequently costly and difficult. All of my experience with Notes since about 2012 has been due to this. This makes it the ultimate legacy app. The IT department wants it gone. The business wants it gone. But it’s just too expensive to quit it and replace it with something newer.

Pega is betting that a number of these large Notes users are ready to possess a more modern solution.

The pain behind old legacy tech

Old technology, like old automobiles, comes with its own baggage. The rapid obsolescence of technology makes today’s hot new tech look absolutely primitive in just a couple of years.  For those technologies that provide mission critical and/or competitive advantage, having the most powerful and current technologies can mean that a company, minimally, remains viable and prospering. Hanging onto a technology when newer, better technology is available can be ill-advised and should be avoided whenever possible and pragmatically feasible.

Some of the problems with older legacy apps could include:

• Missing (or no) documentation
• Out of date documentation & help text
• Nonexistent or outdated data dictionary
• Data meanings in this app may not match those in other apps
• Old, brittle and/or hardwired integrations
• Ancient user interface/experience
• Single path workflows
• Out of date user support documentation
• Only supports one language
• Few or no programmers left to support these solutions
• No IT people want to base their long-term career success on a dying set of technology tools
• Vendor support for the tools or apps has flagged for years
• The ownership of the apps or tools vendor has changed, possibly more than once, with new owners having their own ideas as to what is supported, how it is supported (if at all) and what this will cost
• Software uses archaic file access methods (e.g., VSAM) and is deployed in a non-cloud manner
• App was built on old, proprietary language/tools
• Changing business circumstances may dictate a rethink/reimagining of the application

The problems with old and technically obsolescent technology aren’t just limited to the impact it has on the firm using the software. The impacts can extend to the customers and suppliers of a firm as these additional entities may interact with the software, too. Functionality like payment portals, customer self-service apps, customer order entry apps, etc. are all at risk whenever customers encounter clunky, slow, non-intuitive and/or limited technologies. For example, a company might really be attached to its 25+ year old custom billing software but its customers might not like the product’s slow speed and lack of support for newer payment methods (e.g., p-card, ACH, crypto, etc.).

So, why don’t companies upgrade their software in a timely fashion and avoid the creation of a technical debt situation? There can many reasons for this including:

• The cost to upgrade the technology is prohibitive (cost)
• There is no budget to afford such an upgrade (cost)
• The upgrade would disrupt current business operations (business disruption)
• Few/No skilled personnel available to complete the upgrade (human capital)
• Company personnel no longer want the incumbent solution and don’t want to invest more time and money with the old solutions (desire for change)
• Other projects have a higher priority (prioritization)
• The software vendor’s ownership has changed in a negative way (ownership)
• The software vendor has raised the usage, maintenance and upgrade pricing to an unacceptable level (cost)
• The software has security issues that represent unacceptable risks to the company and its reputation (risk)
• The software vendor is no longer supporting the product or is only providing minimal product upgrades (obsolescence)
• Better solutions are now available (obsolescence)

What all this means is that old apps can be highly problematic for the users of those solutions. This is true whether the old apps are from software firms or custom bespoke software apps/tools that the customer constructed on their own.

Pega Blueprint - the origin story

At the June 2025 Pega user conference, Pega executives announced the availability of Pega Blueprint. In a diginomica piece re: that conference, we noted:

The technical debt problem is material but it is one that can be addressed. Pega’s response was to create: Blueprint. Blueprint can be used to create all-new applications or to renovate a pre-existing application. For the renovation use case, Blueprint requires users to provide application documentation and other inputs to help this AI tool learn what the old application does. In a demo shared with analysts and show attendees, Pega showed how a demonstration video of an old green screen application could be used to help train Blueprint on the capabilities of an existing application. Brent Leary of CRMPlayaz recorded this part of the demonstration. Click on this link and proceed to the 31 minute, 31 second mark to watch this (The stopping point is at 34 minutes).

In the net-new scenario re: Blueprint:

Users just need to describe the app they want to build in natural language, and Pega Blueprint then provides new workflow suggestions, data models, personas, etc. to drive the app.

Blueprint can ingest video, pdfs, user documentation, screenshots and more.

Not only does Blueprint learn from these inputs but it also generates proof of concept templates for modernized applications. I saw it create chatbots, applets and more. Are these fully functional and ready for customer deployment? Not quite, but according to a Pega employee:

Pega Blueprint gets users a good 80% of the way there on the initial design it instantly creates, from which users can then make tweaks and approve the design as they see fit. Also, Pega Blueprint addresses the ‘design’ side of the app dev equation. To develop them into fully functioning apps, the Blueprint design is ported into Pega Infinity (App Studio, more specifically) for development and eventual deployment.

The new applications had modern user interfaces (UI) utilizing the program logic in the original programs.

Blueprint’s value in legacy application transformations originates in the way it reimagines old code. Post-blueprint activity, users can use Pega’s no/low code and other tools to finish out the application modernization.

At this point, customers can use other Pega tools (e.g., APIs, integration technology, RPA, etc.) to connect more of their applications to the Blueprint modernized apps. These connections aid in building modern application workflows and delivering additional value. This is where Pega’s Agentic Process Fabric comes in.”

The market opportunity Pega sees

A statistic by Pega notes that “the average enterprise wastes $370 Million+ on technical debt.” While I’m not aware of the source for this statistic, I suspect the amount varies a lot based on several factors like company size and the numbers of apps needing upgrading/replacing. Regardless, technical debt estimates can be daunting. Companies acquire material amounts of technical debt because the cure is often very expensive and the process to deal with it is fraught with risks.

Tools that make technology upgrades easier, faster and lower risk should make the reduction of technical debt ever more feasible. AI technologies possess the potential to make net-new apps quickly and rehabilitate old apps fast, as well. In short, that’s the Pega Blueprint market opportunity.

The best target customers Pega could have for reducing technical debt might include:

• Larger enterprises as they have the largest problems, potentially larger budgets, etc. and potentially lots of technical debt
• Industries with a large percentage of laggard and late majority technology buyers
• Users of older technologies that have either reached or will soon reach EOL (end of life)
• Companies in industries where custom or bespoke software is prolific
• The installation base of other application software products where vendors have: experienced a material change in control (e.g., new private equity ownership); changed the application’s future direction in ways customers don’t want (e.g., forcible conversion to a different product); or, been notified of upcoming and significant price increases.

Pega has already lined up one target market for its newest Blueprint solution: Notes customers.  Pega believes there are some 34,000 firms using Lotus Notes. To address that market, Pega has created a solution called Notes to Blueprint™.

What is Notes to Blueprint?

Notes to Blueprint is a specific set of capabilities tailored to understand the contents of a customer’s Notes environment including forms, Domino database content and more. Notes to Blueprint utilizes previously discussed capabilities in Pega Blueprint™ while also leveraging the software and experts Pega recently acquired in the Adopteq deal.   According to Pega:

Based on assets recently acquired from legacy transformation solution provider Adopteq, Notes to Blueprint with Pega Blueprint empowers enterprises with the fastest and most comprehensive platform to transform Lotus Notes applications into modern, cloud-native workflows. The solution is available both as an end-to-end modernization solution through Pega premier partner Capgemini on AWS Marketplace, as well as a standalone tool available on Pega Marketplace.

Adopteq brings a lot to this solution. More specifically:

Pega acquired InvestigatorPlus, which analyzes existing Lotus Notes installations, and MigratorPlus, which transfers legacy data from Lotus Notes onto more modern platforms. In addition, select Adopteq employees, including cofounders Viktor Jansson and Mats Jansson, will join Pega.

Capgemini’s contribution to this solution rounds out the picture. They are providing “CAALM (AI-assisted Legacy Modernization) services and expertise – which includes data migration, validation, testing, and change management.”

Pega believes these tools will enable customers to:

• “Understand the full picture of their Lotus Notes estate: Notes to Blueprint securely analyzes Lotus Notes databases to generate a portfolio analysis – giving insight into the size, activity, complexity, and utility of their Lotus Notes applications. This lets enterprises uncover the full project scope, settling the stage for modernization.
• Extract trapped data and processes: Notes to Blueprint then scans proprietary NSF databases to build a comprehensive analysis of application functionality – including data structures and uncovered automations scattered across LotusScripts, forms, and agents.  
• Reimagine collaboration experiences into automated workflows, fast: Import data and processes gleaned with Notes to Blueprint directly into Pega Blueprint, where design agents will reimagine previously scattered logic into fully orchestrated processes incorporating industry best practices, automations, and AI. Through Pega Blueprint, business and IT can quickly collaborate on further evolving and refining requirements for new cloud solutions.
• Accelerate data migration to fuel reporting, AI, and automation: Pega Blueprint automatically maps extracted document-centric data structures from Notes to Blueprint into new relational data models, which are immediately accessible as modern cloud integration APIs and data streams. This enables enterprises to unlock and scale previously trapped data across the enterprise.”

My take

The decision to target the Notes customer base with this Blueprint solution may have been a good choice on Pega’s part. This market segment checks a lot boxes as a potentially good place to find a significant number of Notes customers that possess out of date implementations. However, companies with old apps and a lot of technical debt are often resource constrained or cheap. There’s a reason they haven’t upgraded these apps previously and that constraint may need to be dealt with first.

Not all older apps are good candidates for Blueprint technology. Some apps could be tough to rework due to the intense amount of business intelligence embedded in the application software code. For example, a homeowners insurance system I designed in the 1980s had incredible amounts of logic to handle very specific requirements for rating and underwriting potential policies based on oft-changing state regulations and type of coverage requested. An AI tool that builds new code from a video would need to see thousands of user videos to document the myriad combinations of regulatory, rating and other factors in that system. In other words, some apps (e.g., form filling apps) could be a great fit for Blueprint and some may not. Regardless, there could be plenty of opportunities out there to keep Pega and its partners busy for years.

And, of course, readers will need to respect the IP (intellectual property) of a software vendor. Using a tool like Blueprint on your own bespoke custom apps is fine. But, using Blueprint to create a highly similar app that infringes on a third party’s copyright is unacceptable and could trigger litigation and other adverse consequences. In other words, choose your Blueprint targeted applications carefully.

Finally, readers should keep in mind that their ultimate end goal is NOT to create a lookalike app but to reimagine how a new app would work in today’s world while taking advantage of all that modern apps can access (e.g., new workflows, advanced analytics, agentic AI, algorithmic tools, generative AI, AI architectures, hyperscaler capabilities, etc.).  The goal for users is not to replicate but to reinvent. That’s the ticket to deriving material strategic/competitive advantage and value. It’s what’ll make your apps reinvention efforts ‘notable’.