Legacy System Modernization: The Definitive Guide for Enterprise IT Leaders
Across industries worldwide, enterprise IT leaders face the same dilemma: critical business systems running on 15-, 20-, or even 30-year-old technology stacks. These legacy systems still handle core business processes — transaction processing, customer records, supply chain management — but they are increasingly expensive to maintain, difficult to change, and incompatible with modern cloud-native and AI-driven architectures. Legacy system modernization is the strategic answer to this challenge. This guide provides a comprehensive, decision-maker-focused examination of what legacy system modernization is, how to choose the right approach, and how to execute a modernization initiative that delivers measurable business value.
What Is Legacy System Modernization?
Legacy system modernization is the strategic process of updating or transforming outdated software systems, applications, and IT infrastructure to align with current business needs, technology standards, and security requirements. It is not merely about replacing old technology with new — it is about evolving the foundational systems that power an enterprise so they become more agile, scalable, secure, and cost-effective over the long term.
Defining a legacy system
Contrary to common belief, a system is not defined as “legacy” solely by its age. A well-maintained system built 20 years ago that remains efficient, secure, and adaptable may not be a legacy system. The term describes systems that exhibit several of the following characteristics:
| Characteristic | Description | Business Impact |
|---|---|---|
| Outdated technology stack | Built with programming languages and frameworks no longer actively supported (e.g., COBOL, FORTRAN, obsolete Java versions) | Difficulty finding skilled developers; vendor support ended |
| Monolithic architecture | Tightly coupled codebase where changing one component frequently breaks others | Slow release cycles; high regression risk |
| High maintenance costs | Disproportionate IT budget spent on keeping the system running instead of innovating | Up to 80% of IT budgets consumed by maintenance |
| Security vulnerabilities | Unpatched exploits, outdated encryption, lack of modern access controls | Increased risk of data breaches and compliance penalties |
| Scalability limitations | On-premises hardware constraints; inability to scale horizontally | Performance degradation under load; lost revenue during peak periods |
| Integration barriers | No modern APIs; reliance on batch files, FTP, or point-to-point connections | Data silos; inability to connect with cloud services and modern SaaS platforms |
| Knowledge silos | System knowledge held by a small number of senior engineers nearing retirement | Business continuity risk; institutional knowledge loss |
Legacy system vs. legacy application: understanding the scope
While the terms are often used interchangeably, there is a distinction worth noting. Legacy application modernization typically focuses on updating individual software applications — rewriting or refactoring specific programs. Legacy system modernization is broader in scope. It encompasses the entire ecosystem: applications, databases, middleware, infrastructure, network architecture, and the operational processes wrapped around them. An enterprise undertaking system modernization is addressing the full technology stack rather than isolated components.
A brief history: why legacy systems persist
The persistence of legacy systems is not a failure of IT management — it is a rational consequence of business continuity requirements. Mainframes and mid-range systems installed in the 1980s and 1990s were built to be highly reliable, handling millions of transactions without interruption. Replacing them carries real risk. Many of these systems run on COBOL, a language created in 1959, yet COBOL-based systems still process an estimated 70% of global business transactions. The Y2K remediation effort demonstrated the massive scale of this dependency — and also taught many organizations that it was cheaper to keep systems running than to replace them entirely. That calculus has now shifted. The cost of maintaining aging infrastructure — in talent, security, and lost agility — has crossed the threshold where modernization is no longer optional.
What Are the Signs Your Legacy System Needs Modernization?
7 warning signs IT leaders should not ignore
- IT maintenance consumes 70–80% of the technology budget. When nearly all resources go to keeping existing systems running, there is nothing left for innovation. According to Gartner, enterprises spend approximately 40% of their total IT budgets on technical debt alone.
- Deploying a single change takes weeks. If every modification requires extensive regression testing and manual coordination across multiple teams, the architecture is acting as a bottleneck.
- The system has experienced a security incident in the past 12 months. Outdated security controls make legacy systems prime targets. The 2024 IBM Cost of a Data Breach report found that organizations with significant legacy infrastructure had a 26% higher average breach cost.
- Integration requests are rejected or take longer than three months. When connecting the legacy system to a modern SaaS platform or cloud service becomes a major project, the system is actively impeding digital transformation.
- Only two or three people in the organization understand the system. Key-person dependency is one of the highest risks an enterprise can accept. If those individuals leave, the business could lose the ability to operate critical systems.
- The system cannot scale to meet business growth. If adding capacity requires months of hardware procurement and infrastructure work rather than elastic cloud provisioning, the system is holding growth back.
- Auditors or regulators have flagged compliance gaps. Modern frameworks require robust audit trails, encryption at rest and in transit, and granular access controls — features that legacy systems rarely support natively.
The hidden cost of doing nothing
The decision not to modernize is itself a strategic choice — and one with significant financial consequences. The following table illustrates a typical 5-year cost comparison for a mid-market enterprise running a core legacy system serving 10,000 users:
| Cost Category | Maintain (5-Year Total) | Modernize (5-Year Total) | Modernization Savings |
|---|---|---|---|
| Hardware and infrastructure | $850,000 | $320,000 | $530,000 |
| Software licenses and maintenance | $620,000 | $180,000 | $440,000 |
| Staff (specialized talent premium) | $2,400,000 | $1,200,000 | $1,200,000 |
| Security incidents and compliance | $480,000 | $90,000 | $390,000 |
| Lost opportunity cost (delayed features) | $1,500,000 | $350,000 | $1,150,000 |
| Total | $5,850,000 | $2,140,000 | $3,710,000 |
These figures are illustrative but grounded in industry benchmarks. The U.S. Government Accountability Office has reported that some federal agencies spend up to 80% of their IT budgets maintaining legacy systems. For commercial enterprises the number is typically lower — 60–70% — but still represents a fundamental misallocation of technology investment.
When modernization is not the right answer
Not every legacy system needs modernization. If a system is stable, secure, well-documented, and adequately performing for its intended purpose — and it does not need to integrate with modern platforms — deferring modernization is a valid decision. Similarly, if the system supports a business process that is itself being retired or replaced, the better choice may be to replace the system entirely with a SaaS or off-the-shelf solution rather than invest in custom modernization. The key is making that assessment deliberately rather than defaulting to inaction.
What Are the 7 Legacy System Modernization Strategies?
The most widely referenced framework for legacy modernization strategies is Gartner’s “5 Rs” — rehost, replatform, refactor, rebuild, and replace. Two additional strategies — the strangler fig pattern and encapsulation — are important variations that deserve attention in their own right. Together, these seven approaches form a comprehensive toolkit for enterprise IT leaders.
The classic 5 Rs framework
Rehost (lift and shift)
Rehosting moves an application to a new infrastructure — typically a cloud environment — without changing the code or architecture. The system behaves identically; only the underlying hardware changes. This is the fastest and lowest-risk strategy. It is best suited for applications that run well but are constrained by aging on-premises hardware. The drawback is that rehosting does not address technical debt or architectural limitations.
Replatform (lift, tinker, and shift)
Replatforming is a light modernization: the application is moved to a new platform with targeted optimizations — migrating from a self-managed database to a managed service, for instance, or updating the runtime environment. The core application logic remains unchanged. This approach offers better operational improvements than rehosting while still avoiding the cost and risk of a full redesign.
Refactor / Rearchitect
Refactoring improves the internal structure of the code without changing its external behavior. Rearchitecting goes further, changing the fundamental design — breaking a monolith into microservices, introducing event-driven architecture, or adopting a cloud-native design. This is where the most significant long-term value is realized, but it also requires the most engineering skill and carries higher regression risk.
Rebuild
Rebuilding means rewriting the application from scratch using modern technology while preserving the same business functionality. This is the most expensive and time-consuming approach. It is the right choice only when the existing codebase is so degraded that it cannot be refactored safely, the technology is completely obsolete, and the business logic can be fully documented and recreated.
Replace
Replacement involves decommissioning the custom legacy system and adopting a commercial off-the-shelf (COTS) or SaaS product. This works well for standard business functions — HR, finance, CRM — where the organization does not need a custom solution. The trade-off is reduced flexibility and the challenge of migrating years of accumulated organizational data into a new system.
Beyond the 5 Rs: the strangler fig pattern
Named after the tropical tree that grows around a host and gradually replaces it, the strangler fig pattern involves building a new system incrementally alongside the existing one. Traffic is progressively routed from the old system to the new components until the legacy system can be decommissioned. This pattern minimizes risk because the old system remains operational throughout. It is ideal for large, complex systems where a big-bang cutover is unrealistic. The main challenges are data synchronization between the two environments and the operational overhead of running parallel systems.
Encapsulation (API wrapping)
Encapsulation wraps the legacy system in a modern API layer without modifying the underlying code. The system’s functions are exposed through RESTful or GraphQL interfaces that modern applications can consume. This approach is fast and preserves the existing investment, but it does not address the underlying technical debt. It is well-suited for systems that still deliver business value and are reasonably stable, but cannot integrate with modern tools.
Comparison of all 7 strategies
| Strategy | Effort | Cost | Risk | Timeline | Addresses Technical Debt | Best For |
|---|---|---|---|---|---|---|
| Rehost | Low | $10K–$100K | Low | 2–6 months | No | Fast cloud migration; hardware refresh |
| Replatform | Low–Medium | $50K–$250K | Low–Medium | 3–9 months | Minimal | Optimizing while moving to cloud |
| Refactor | Medium–High | $150K–$800K | Medium | 6–18 months | Yes | Improving maintainability and scalability |
| Rebuild | Very High | $500K–$5M+ | High | 12–36 months | Yes (full) | Degraded codebases; obsolete tech stacks |
| Replace | Medium | $50K–$500K | Medium | 3–12 months | N/A (decommissioned) | Standard business functions with SaaS options |
| Strangler Fig | Medium–High | $200K–$2M | Low–Medium | 6–24 months | Yes (incremental) | Large, complex systems needing zero downtime |
| Encapsulation | Low–Medium | $30K–$150K | Low | 2–6 months | No | Stable systems needing API integration |
How to Choose the Right Modernization Strategy for Your Organization?
Selecting a modernization strategy is not an exercise in picking a favourite approach. It requires a structured evaluation of each system’s characteristics, the organization’s strategic priorities, and the constraints of budget, timeline, and talent availability.
A decision framework for strategy selection
The following decision matrix provides a systematic method for evaluating which strategy fits a given system. Rate each criterion on a scale of 1 (low) to 5 (high) for your specific context, then sum the scores for each strategy.
| Criterion | Weight | Rehost | Replatform | Refactor | Rebuild | Replace | Strangler Fig | Encapsulation |
|---|---|---|---|---|---|---|---|---|
| Business criticality | 30% | 4 | 4 | 3 | 2 | 2 | 5 | 4 |
| Need for scalability | 20% | 2 | 3 | 5 | 5 | 3 | 5 | 1 |
| Risk tolerance | 20% | 5 | 4 | 3 | 1 | 3 | 4 | 5 |
| Budget constraints | 15% | 5 | 4 | 2 | 1 | 3 | 2 | 4 |
| Speed to value | 15% | 5 | 4 | 2 | 1 | 3 | 3 | 5 |
| Weighted Total | 100% | 4.1 | 3.8 | 3.2 | 2.1 | 2.7 | 4.0 | 3.7 |
The weighted totals above reflect a typical enterprise scenario with moderate business criticality, medium risk tolerance, and a reasonable budget. Your own scores will vary based on your organization’s specific context. The value of this framework is not the precise number but the discipline of evaluating options against consistent criteria rather than relying on intuition or vendor recommendations.
Factors that influence strategy choice
- System criticality. Mission-critical systems handling core business transactions require lower-risk approaches — encapsulation or strangler fig — while peripheral systems can be candidates for rebuild or replacement.
- Code quality and documentation. A well-structured, well-documented codebase is a good candidate for refactoring. A tangled, undocumented codebase with no tests may be better suited for rebuilding or replacement.
- Team expertise. If your team has deep knowledge of the legacy platform and modern cloud-native technologies, refactoring or strangler fig is achievable. If the legacy knowledge has already retired, replacement may be the only viable path.
- Regulatory environment. Financial services, healthcare, and public sector organizations face compliance requirements that may constrain the modernization approach. For example, data residency rules may limit cloud options.
Common mistakes in strategy selection
- Applying one strategy across the entire portfolio. Different systems have different characteristics. A single approach rarely works across all applications.
- Choosing rebuild by default. The appeal of a clean slate is strong, but rebuilding is the most expensive and risky approach. Always consider less invasive options first.
- Analysis paralysis. Spending months evaluating options without taking action. A pragmatic approach is to start with a low-risk strategy — rehost or encapsulation — on a non-critical system while running deeper analysis for the core systems.
Practical guidance: If your organization is evaluating modernization strategies and needs experienced guidance, the Greyson IT consulting team can help you design a tailored decision framework and execution roadmap aligned with your specific business context and constraints.
What Does a Legacy System Modernization Roadmap Look Like?
A successful modernization initiative follows a structured, phased approach. The following four-phase roadmap provides a template that can be adapted to any organization’s scale and complexity.
Phase 1: Discovery and portfolio assessment (4–8 weeks)
Map the entire application portfolio. Catalogue every system, its dependencies, its data flows, and its integration points. Evaluate each application against criteria such as business value, technical health, maintenance cost, and risk exposure. This phase produces a prioritized list of modernization candidates.
Phase 2: Strategy selection and prioritization (2–4 weeks)
Apply the decision framework described above to each candidate system. Map results onto a value/effort grid: high-value, low-effort systems are first-mover candidates that build momentum. High-value, high-effort systems require detailed planning. Low-value systems may be candidates for retirement or replacement.
Phase 3: Execution and incremental delivery (6–24 months, depending on scope)
Execute the chosen strategies in defined increments. For refactoring and strangler fig approaches, this follows standard agile delivery with sprint-level planning. Establish CI/CD pipelines early to enable frequent, validated releases. Run the legacy and new systems in parallel where possible.
Phase 4: Validation and decommissioning (4–12 weeks per system)
Validate that the new system meets all functional, performance, and security requirements. Execute a structured cutover plan with rollback capability. Once the new system is verified in production, decommission the legacy system and archive data according to retention policies.
Typical timeline per strategy
| Strategy | Discovery | Strategy Selection | Execution | Validation & Decommission | Total (Estimated) |
|---|---|---|---|---|---|
| Rehost | 4 weeks | 2 weeks | 8–16 weeks | 4 weeks | 4–7 months |
| Replatform | 4 weeks | 2 weeks | 12–24 weeks | 4 weeks | 5–8 months |
| Refactor | 6 weeks | 3 weeks | 24–60 weeks | 6 weeks | 9–19 months |
| Rebuild | 8 weeks | 4 weeks | 48–144 weeks | 8 weeks | 17–41 months |
| Replace | 4 weeks | 4 weeks | 12–40 weeks | 4 weeks | 6–13 months |
| Strangler Fig | 6 weeks | 3 weeks | 24–96 weeks | Ongoing per module | 8–26 months |
| Encapsulation | 4 weeks | 2 weeks | 8–16 weeks | 4 weeks | 4–7 months |
What Are the Biggest Challenges in Legacy System Modernization?
Technical challenges
Undocumented code. Many legacy systems have minimal or no documentation. The original developers are often no longer available. Understanding what the system does — and critically, what edge cases it handles — can be one of the hardest parts of modernization. Characterization tests (tests that capture current behavior without assuming it is correct) are a practical tool for addressing this.
Data silos and integration spaghetti. Legacy systems accumulate point-to-point integrations over decades. These are rarely documented and often have no owner. Untangling them is a prerequisite for any modernization effort that involves changing interfaces.
Testing gaps. Legacy systems often have few, if any, automated tests. Building a regression test suite that provides confidence for changes is a significant upfront investment that many organizations underestimate.
Organizational challenges
Talent availability. Skilled developers for platforms such as COBOL, PL/I, or legacy AS/400 environments are increasingly scarce and expensive. Conversely, the same engineers who deeply understand the legacy system are essential for a successful modernization — yet they are often nearing retirement. The window of opportunity for modernization is narrowing.
Stakeholder resistance. Business stakeholders who rely on the legacy system are naturally risk-averse. If the system “works,” they question why it needs to change. Building trust requires transparent communication, clear business cases, and demonstrable early wins from less critical systems.
Data migration complexity
Data migration is frequently the most underestimated workstream in modernization projects. The following table highlights common pitfalls and their mitigations:
| Pitfall | Consequence | Mitigation |
|---|---|---|
| Incomplete data inventory | Data left behind; business processes break post-migration | Run comprehensive data discovery before migration begins |
| Schema mismatch | Data transformation fails; data loss or corruption | Detailed source-to-target mapping with transformation rules |
| Poor data quality in source | Issues propagate to the new system | Data cleansing as a separate, parallel workstream |
| No rollback plan | Failed migration causes extended downtime | Parallel running; reversible migration scripts |
| Underestimating volume | Timeline overruns; performance issues | Full-volume trial runs with production-scale data |
Practical guidance: Data migration and validation are critical components of any modernization initiative. The Greyson data capability team provides expertise in data architecture, ETL pipeline design, and data quality assurance to support complex migration workstreams.
Risk management during modernization
Every modernization strategy carries risk. The most effective risk management approach is to limit the blast radius of any single failure. This means: prefer incremental over big-bang approaches; maintain the ability to roll back at every stage; invest heavily in automated testing before changing anything; and run old and new systems in parallel for a defined period. Enterprise IT leaders should assume that something will go wrong and plan accordingly — not assume that a well-designed plan will execute flawlessly.
What Is the Role of Testing in Legacy System Modernization?
Testing is not a phase of modernization — it is a prerequisite. Attempting to modernize a legacy system without an adequate test suite is the single most common cause of project failure in this domain.
Why testing is critical during modernization
When you modify a legacy system — whether by refactoring code, moving it to new infrastructure, or wrapping it with an API — you must be able to verify that its behavior remains correct. Without automated tests, every change introduces the risk of regression. With a well-designed test suite, you can refactor with confidence, knowing that any unintended change in behavior will be detected immediately.
Building a test suite for legacy systems
Building tests for a legacy system is different from building tests for a greenfield application. The system was never designed for testability. The practical approach is:
- Characterization tests: Write tests that capture the current behavior of the system — not what the system should do, but what it actually does. These serve as a safety net during refactoring.
- Smoke tests for infrastructure changes: For rehosting or replatforming, focus on infrastructure-level testing: connectivity, latency, data access, and authentication.
- Integration tests: For encapsulation or strangler fig approaches, test the interfaces between the legacy system and new components extensively.
Practical guidance: Establishing a comprehensive testing strategy for legacy modernization requires specialist experience. The Greyson testing services team can help design and implement automated test suites tailored to legacy environments.
Testing strategies for different modernization approaches
- Rehosting: Focus on infrastructure and connectivity testing. Verify that the application behaves identically on the new platform.
- Refactoring: Heavy investment in automated regression testing. Characterization tests followed by unit and integration tests as code structure improves.
- Strangler fig: Dual testing — test the new module independently and test the routing and data synchronization between old and new systems.
- Rebuilding: Build a complete test suite for the new system while using the old system as the reference for behavioral validation.
How to Calculate the ROI of Legacy System Modernization?
Building a business case for modernization requires quantifying both the direct cost savings and the indirect business value. IT leaders who present only the cost side — “modernization costs $500K” — will struggle to secure approval. Those who present both sides — “modernization costs $500K but saves $1.2M in maintenance over three years and enables $2M in new revenue” — build a compelling case.
Direct cost savings
- Infrastructure savings: Reduced hardware procurement, datacenter footprint, and associated facilities costs.
- Software license reduction: Eliminating proprietary middleware, database, and tool licenses that are no longer needed.
- Maintenance overhead: Reducing the specialized staff hours required to keep aging systems operational.
Indirect business value
- Faster time-to-market: Modernized systems enable feature delivery in days rather than months.
- Improved agility: The organization can respond to market changes and competitive threats more quickly.
- Better customer experience: Modern systems support self-service portals, mobile interfaces, and real-time interactions.
3-year TCO comparison: maintain vs. modernize
| Cost/Value Category | Maintain (3-Year) | Modernize (3-Year) | Net Difference |
|---|---|---|---|
| Infrastructure & operations | $510,000 | $195,000 | -$315,000 |
| Software licenses | $375,000 | $110,000 | -$265,000 |
| Staff & contractors | $1,440,000 | $720,000 | -$720,000 |
| Security & compliance | $290,000 | $55,000 | -$235,000 |
| Modernization investment | $0 | $500,000 | +$500,000 |
| Total cost | $2,615,000 | $1,580,000 | -$1,035,000 |
| Revenue impact of new capabilities | $0 | +$1,200,000 | +$1,200,000 |
| Net business impact | -$2,615,000 | -$380,000 | +$2,235,000 |
Measuring success after modernization
Once modernization is complete, IT leaders should track these key performance indicators to validate the expected benefits:
- Deployment frequency: How often can the team release changes to production? A shift from monthly to weekly or daily is typical.
- Mean time to recover (MTTR): How quickly can the team restore service after an incident? Modern observability and automated recovery should reduce MTTR significantly.
- Cost per transaction: The unit cost of processing business transactions, which should decrease as infrastructure efficiency improves.
- Time to integrate: How quickly can the system be connected to a new SaaS or cloud service? Hours or days instead of weeks or months.
How Is AI Changing Legacy System Modernization?
Artificial intelligence is reshaping the modernization landscape, particularly in three areas where traditional approaches have been slow and labour-intensive.
AI-powered code analysis
Modern AI tools can scan millions of lines of legacy code to map dependencies, identify tight coupling, document undocumented logic, and even generate characterization tests. Tools like Kodesage, IBM Watson Code Assistant, and various GitHub Copilot extensions are making it practical to understand a legacy codebase in weeks rather than months. This dramatically reduces the uncertainty that makes modernization initiatives hard to scope and estimate.
Automated code translation
AI-assisted translation of legacy code — from COBOL to Java, for instance — has moved from research to production in the past two years. These tools do not produce perfect output; the translated code still requires human review and testing. However, they can accelerate the initial translation by 40–60%, freeing senior engineers to focus on architecture and validation rather than line-by-line manual translation.
Limitations of AI in legacy modernization
AI is a powerful accelerator, but it is not a replacement for human judgment in modernization. AI tools cannot understand business context, make architectural trade-off decisions, or design migration strategies. They cannot validate that the modernized system meets regulatory requirements or ensure that business logic embedded in institutional knowledge — not in code — is preserved. The most effective modernization initiatives combine AI-assisted tooling with experienced human architects and engineers who understand both the legacy domain and modern platforms.
Practical guidance: If your organization is planning a legacy modernization initiative that includes AI-assisted analysis or redevelopment, the Greyson software development team combines deep experience in legacy platforms with modern cloud-native engineering to deliver pragmatic, risk-managed modernization outcomes.
Frequently Asked Questions
What is legacy system modernization in simple terms?
Legacy system modernization is the process of updating old, outdated computer systems so they work better with current technology. It can involve moving systems to the cloud, rewriting parts of the code, or wrapping them with modern interfaces — all with the goal of making the system cheaper to run, more secure, and easier to integrate with modern tools.
What are the 5 Rs of legacy modernization?
The 5 Rs are a framework developed by Gartner for classifying modernization strategies: Rehost (move without changing code), Replatform (move with minimal optimizations), Refactor (restructure internal code), Rebuild (rewrite from scratch), and Replace (decommission and adopt a SaaS or COTS product). Two additional strategies — the strangler fig pattern and encapsulation — extend this framework to 7 approaches.
How long does legacy system modernization take?
The timeline depends heavily on the chosen strategy and system complexity. Simple rehosting can take 4–7 months. Refactoring typically requires 9–19 months. A full rebuild can take 17–41 months. Most enterprise modernization initiatives fall in the 6–24 month range when using incremental approaches like the strangler fig pattern.
How much does legacy system modernization cost?
Costs vary widely. A rehosting project for a single application may cost $10K–$100K. Refactoring a complex system can run $150K–$800K. A full rebuild of a mission-critical system can exceed $5M. The total cost of ownership comparison — factoring in ongoing maintenance savings — typically shows a positive return within 2–3 years.
What is the easiest modernization strategy?
Rehosting (lift and shift) is the lowest-effort and lowest-risk strategy. It moves the application to modern infrastructure without changing the code. It does not address technical debt, but it can provide immediate cost savings and serve as a first step toward deeper transformation.
What is the strangler fig pattern?
The strangler fig pattern is an incremental modernization approach where you build new system components alongside the existing legacy system and progressively route traffic from the old to the new. The legacy system is decommissioned only after all functionality has been replaced. It is ideal for complex systems where downtime is unacceptable.
Is legacy system modernization worth the investment?
For the vast majority of enterprises, yes. The direct cost savings from reduced infrastructure, licensing, and maintenance — combined with the indirect value of faster innovation, improved security, and better scalability — deliver a compelling return on investment. Most organizations recover their modernization investment within 2–3 years through operational savings alone, not counting the revenue benefits of new capabilities.