Legacy Application Modernization: How To Future-Proof Your App

Outdated software costs more than most businesses expect.

Legacy application modernization debt surfaces first in the engineering budget. Teams spend the majority of their time patching and stabilising rather than building.

Roadmaps stall and developer productivity drops with them.

Meanwhile, a competitor ships the capability you have been planning for eighteen months. The competitive advantage gap between organisations that have modernised their infrastructure and those that haven’t is widening.

This guide gives you the clarity to make that call. By the end of it, you will be able to:

• Recognise the warning signs that your infrastructure is costing more than it should
• Understand the main approaches and when each one applies
• See the concrete business case — cost reduction, speed, security, competitive position
• Know how AI is accelerating legacy app modernization projects in 2026
• Identify what to look for when choosing a partner

The first question worth answering, before any decision about approach or investment, is a more fundamental one. 

What makes software “legacy,” and how do even well-built apps reach that point?

What Are Legacy Applications and How Do Systems Become Outdated?

A tool does not become outdated simply because it is old. What matters is whether it can support the business reliably. When it can’t, the label fits regardless of how long the software has been running.

Outdated software is typically defined by what it can no longer do. 

• The vendor has stopped releasing updates.
• The frameworks it runs on are unsupported.
• Connecting it to modern tools requires expensive custom work. 
• Security gaps accumulate because patches are no longer available. 

At its core, what is legacy application modernization becomes clear when you look at what a solution can no longer do. The real cost is what the business pays to work around those limits every day.

Software reaches this point through compounding factors, rarely through a single event. An upgrade gets deferred. A vendor announces end-of-life for a platform the business depends on.

The team that built the tool moves on. Documentation is thin or missing. Each of these adds to the technical debt already carried by the code. Over time, the cost of change rises sharply.

A useful first test is to check your platforms against these indicators:

• Vendor support has ended — the platform or framework no longer receives updates or security patches
• Integration requires heavy custom work — connecting to modern APIs or third-party tools is slow and expensive
• The codebase is poorly documented — new developers struggle to understand how the solution works
• Scaling is difficult or impossible — the software cannot handle increased load without significant rework
• Security standards are no longer met — known vulnerabilities exist with no clear path to remediation

Two or more of these indicators signal that action may be needed.

If two or more apply, the gap between current state and what the business needs is already measurable. Legacy application modernization is the structured way to close it.

How to Tell When You Need Legacy Application Modernization: 5 Red Flags

The five indicators below cover the most common points where aging software starts costing more than it should. Catching them early is what separates a controlled upgrade from a crisis-driven one.

High Maintenance Costs

Every piece of software requires upkeep. The question is how much, and what that overhead is displacing.

When software maintenance and support starts consuming the majority of the engineering budget, the root cause is rarely a resourcing problem. The codebase has accumulated enough complexity that routine changes carry disproportionate risk. Fixes take longer. Every deployment requires more testing than it should.

Vendor lock-in makes the situation worse. When a supplier reaches end-of-life on a component the tool depends on, the internal team inherits full responsibility for supporting it. There is no upstream patch. There is no vendor escalation path. The overhead lands entirely on the engineering team.

The opportunity cost is where the real damage accumulates. Engineers spending their time on upkeep are not shipping features. Roadmap items get pushed. Competitors move faster. Teams that modernise typically see reduced maintenance cost within the first year, as engineering time shifts from reactive support to productive development.

Signs this flag applies to what you are running:

• Routine changes regularly take longer than planned
• A significant share of sprint capacity goes to maintenance tickets
• The team avoids touching certain parts of the code
• Vendor support for a core component has ended or is approaching end-of-life

Poor Performance and Scalability

Users notice performance problems before engineers do. Pages load slowly. Actions time out. The experience degrades in ways that are hard to ignore and easy to abandon.

The technical cause is usually structural. Tools built a decade ago were designed for a specific load profile and a specific infrastructure model.

When traffic grows or usage patterns shift, the architecture does not adapt. Adding more servers addresses symptoms without resolving the constraint. The degradation continues.

Horizontal scaling is where the gap becomes most visible. Modern cloud infrastructure assumes tools can distribute load across instances. Many older platforms were designed as single-node deployments. They cannot scale that way without significant rework to the underlying architecture.

The business impacts compounds quickly. Slow response times increase abandonment rates. Performance issues under load surface during the moments of highest visibility, including launches and seasonal peaks. The system fails precisely when reliable performance matters most.

Data Silos and Integration Problems

Modern operations depend on data moving cleanly between tools. When an app cannot connect to that flow, every team that depends on it works with incomplete information.

Integration failures are the most immediate symptom. A CRM cannot pull order history from the database. An ERP cannot reconcile data from a billing platform. Every connection requires expensive custom development and becomes a maintenance liability of its own.

The result is a fragmented data estate. Without a unified data layer, departments operate from disconnected snapshots and reporting becomes a manual exercise. Data used for decisions can be days or weeks out of date. The cost of maintaining that workaround grows every quarter.

What makes this flag significant in 2026 is the pace of API-driven tooling adoption. Modern platforms assume clean integration as a baseline. A solution that cannot meet that baseline becomes progressively harder to include in the broader technology stack.

Compliance and Security Exposure

Security exposure and compliance vulnerability are closely related, but they do not always surface at the same time. An organisation can fail a regulatory audit before a breach occurs. Both outcomes trace back to the same root cause.

Once end-of-life support expires, two risks open at once. Vulnerabilities go unpatched because the vendor has stopped releasing fixes. Regulatory frameworks such as GDPR, HIPAA, and PCI DSS, in turn, assume a level of security control that aging dependencies can’t provide.

Audit failures carry direct financial consequences:

• Regulatory fines — penalties under GDPR can reach 4% of annual global turnover
• Remediation costs — emergency patching and incident response consistently exceed planned investment
• Reputational exposure — a disclosed breach affects customer trust in ways that financial penalties do not capture

Unpatched CVEs are the most common vector. Attackers target known vulnerabilities in unsupported software precisely because the fix does not exist.

These vulnerabilities are publicly catalogued. Attackers exploit them because no fix is coming.

Inability to Integrate AI or Modern Tools

On aging stacks, AI adoption gaps translate into competitive exposure.

Teams on a monolithic architecture cannot easily add AI services. LLM-based tools need clean API interfaces. Tightly coupled systems do not expose them. Adoption is blocked before it starts.

Without the decoupling that cloud-native monitoring and continuous delivery pipelines require, older apps cannot provide the operational visibility modern engineering depends on. The constraint is built into the architecture. It requires a structural change to address.

Competitors on modern stacks are already shipping AI-assisted features across support, operations, and customer experience. That gap widens with every release cycle. For most industries, catching up requires addressing the underlying architecture.

Why You Should Invest in Legacy Application Modernization

Modernizing an aging solution requires investment. That is the objection most organisations raise first, and it is a fair one.

The full business case for legacy app modernization extends well beyond resolving technical debt. The returns show up in engineering capacity, release velocity, security posture, and the ability to compete on capability.

The reluctance to act is understandable. Upfront costs are visible. The cost of inaction is distributed and hard to quantify. It builds across budgets, timelines, competitive exposure, and delivery velocity.

The damage is visible only after it has already compounded.

At that point, the distance between where the tool is and where the business needs it to be is already significant.

High Maintenance Costs

As complexity accumulates, maintenance spending on an outdated solution grows. Dependencies age out of support, and the architecture accumulates workarounds around parts too entangled to change directly.

The ROI case is built on cost avoidance. The budget that currently goes to upkeep becomes available for software development. Engineering capacity shifts from reactive to productive. 

Organisations that have gone through a structured overhaul consistently report significant first-year cost reductions. Maintenance overhead drops, and a portion of the initial investment is offset within twelve months.

Poor Performance

After migration, performance improvements are measurable and direct. Platforms rebuilt on modern infrastructure handle higher load and recover faster from failures.

The business impact shows up in two places.

1. Faster time to market follows from improved release velocity. On modern stacks, release frequency increases and deployment exposure drops.
2. Improved scalability means the solution can grow with demand without requiring architectural intervention at every traffic inflection point.

User retention is the downstream consequence. Slow, unreliable software loses users to alternatives. A modernized tool holds them.

Data Silos

Eliminating data silos produces compounding returns. A unified data layer makes real-time analytics possible and enables cross-system workflow automation. Every team works from the same version of operational data.

The integration unlocks are immediate. CRM, ERP, billing platforms, and communication tools connect cleanly. 

Cross-system reporting that previously required manual consolidation becomes automated. Decisions get made on current data.

Compliance Issues

Modernizing an inherited solution requires investment. Replacing them with supported, auditable components closes the exposure that builds from running past end-of-life support windows. Brought current layer by layer, the stack becomes auditable by default.

A consistently reported outcome of a structured upgrade is an enhanced security posture. Audit readiness improves because the controls auditors expect are already in place. Reactive remediation gives way to planned maintenance.

Lack of Security

Security debt accumulates the same way technical debt does.

Each deferred update, each unsupported dependency adds to the exposure the product carries. At some point, the accumulated liability exceeds what the business can absorb.

The shift to proactive security management requires a supported stack. Without vendor updates, the team has no reliable mechanism for addressing known vulnerabilities. Every incident response is reactive by definition.

On modern stacks, vendor updates arrive on a predictable schedule.

Before vulnerabilities are exploited, they are patched. Proactive patching produces measurable system reliability. Unplanned downtime drops, and engineering time shifts to planned work. When audit cycles come around, the evidence of current controls is already in place.

Here is the full revised section.

How to Modernize Legacy Applications: 2 Essential Steps

Starting without a clear picture is how projects encounter avoidable surprises. Structuring legacy application modernization as a two-step process reduces both risk and scope creep. 

The first step establishes what you are working with. 

The second one determines how to proceed.

Step 1. Evaluate Your Legacy System

The full scope of application modernization for legacy systems begins with a structured audit. A codebase audit surfaces technical debt and maps the dependencies the infrastructure carries: dead code and tightly coupled components that no longer serve a clear purpose. Without this baseline, decisions rest on assumptions.

A risk assessment follows from those findings. Through dependency mapping, the components carrying the highest replacement complexity become visible. 

An infrastructure review then identifies what the current environment can and cannot support, narrowing the viable option set before any approach is chosen. Static code analysis tools accelerate both passes significantly.

Keeping an old stack running and replacing it require different skills. Identifying that gap early is what makes resourcing decisions accurate before the project scope is set.

Step 2. Choose a Proper Modernization Approach

The right approach depends on what the evaluation reveals. The right legacy application modernization strategy depends on risk tolerance and the condition of the codebase the evaluation has revealed.

Six options cover the full range of situations.

• Rehosting (lift and shift). The platform moves to a new infrastructure without any code changes. For those that need to exit an on-premises environment quickly, this is the natural starting point.
• Replatforming. With minimal code changes, software migrates to a different platform or runtime. Some benefits of a modern environment become available without the cost of a full rebuild.
• Refactoring. The existing codebase is restructured to reduce technical debt. Core logic is preserved, and the solution becomes easier to maintain and extend.
• Re-architecting. The underlying structure changes to support new capabilities. When the existing architecture is the primary constraint on what the product can do, this is the path forward.
• Rebuilding. The app is redeveloped from scratch, with scope and specification kept intact. Accumulated debt that cannot be recovered incrementally makes this the right choice.
• Retiring. When a solution no longer serves a business need, replacing or decommissioning it is the most efficient path. An off-the-shelf solution often covers the remaining requirement.

For organisations that cannot afford a full rebuild, incremental refactoring is the most common legacy application modernization strategy. It minimises disruption by keeping the solution in production throughout the process.

Legacy Application Modernization Strategies

The right strategy depends on what the evaluation reveals about the system and what the business can absorb during the transition. Some approaches preserve continuity while gradually replacing components. Others require a more deliberate commitment to structural change. The five strategies below address the full range of situations that arise.

Strangler Fig Pattern

Traffic routes to new services as the existing deployment continues running. As each new service takes over a defined slice of functionality, the old codebase shrinks. No single cutover event is required.

Without a gradual replacement mechanism, developers face a binary choice. The options are limited: commit to a full replacement before it is validated, or keep the source environment running indefinitely.

Each stage of the strangler fig pattern is independently testable and reversible. Testability and reversibility at each stage make the strangler fig pattern the preferred approach for platforms that cannot afford downtime.

Incremental Refactoring and Modularisation

A monolithic codebase carries compounded fragility.

Changes to one component affect others in ways that are difficult to predict without clear boundaries in place. Incremental refactoring draws those boundaries first, then improves each module independently.

Without this separation, every change is a system-wide event. Reducing vulnerability requires modularisation before rewriting begins. Each improved module reduces the complexity the next change has to navigate, and the app stays in production throughout. 

For teams that cannot afford a full rebuild, this is the most common legacy application modernization strategy.

Microservices Migration

One business capability per microservice is the core design principle. Communication happens through a defined API, which means updating or redeploying one service requires no changes to adjacent ones. The solution stays coherent as components evolve independently.

Releases stop being coordinated events. Each service connects to its own CI/CD pipeline, and a change to one service deploys on its own schedule. The rest of the code is unaffected.

Cloud-Native Re-Architecting

Before committing to cloud-native re-architecting, a phased modernization roadmap is essential. Dependencies between components need to be understood before migration begins. Without the dependency map, scope grows unpredictably and migration stages lose their boundaries.

What follows is a compounding infrastructure advantage. The tool scales on demand and recovers from failures automatically. The observability that cloud-native environments provide changes how engineers work — incidents get detected earlier and resolved with less manual effort.

Containerisation and DevOps Enablement

Packaging software and its dependencies into portable units is what containerisation does. Using Docker, those units run consistently across environments. Kubernetes then orchestrates deployment and recovery without manual intervention.

Testing and deployment cycles run automatically through CI/CD pipelines. The danger per release drops as deployment frequency increases. Shipping more often and shipping safely become the same thing.

Together, these two layers change how a modernized app is maintained. Infrastructure events that once required manual response are handled automatically. Building replaces operating as the default engineering activity.

AI and GenAI in Legacy Application Modernization

AI tooling has changed what is possible. Tasks that previously required weeks of manual analysis — mapping dependencies, identifying dead code, generating test coverage — now complete in hours. 

The most significant shift is that legacy application modernization with gen AI has moved from experimental to production-ready. AI-assisted modernization is no longer a specialist capability. In 2026, it is standard practice in how structured programmes are delivered.

AI-Assisted Code Analysis and Migration

At scale, manual codebase analysis breaks down. The one with hundreds of thousands of lines cannot be mapped accurately by a team working through it manually. AI tooling changes that constraint fundamentally.

Dependency graphs built by AI tools surface the full relationship map between components, including connections that are not visible in documentation. When a dead code detection pass runs alongside that analysis, the scope of what actually needs to be migrated becomes precise. Vulnerability mapping adds a third layer — security exposure is identified at the same time as structural debt, not in a separate audit cycle.

The combined output is a baseline that would take a manual review team weeks to produce. Migration decisions rest on evidence rather than estimation from the start.

GenAI for Automated Refactoring and Documentation

Tools built for GenAI code migration convert inherited code — COBOL, Java, or Python — to modern equivalents with a human review layer retained throughout. The model proposes the refactored output. An engineer validates it. That division of labour is what makes the process faster without removing human judgement from the critical path.

Intelligent documentation generation runs in parallel. Inline comments, API specs, and module-level documentation are produced automatically as refactoring progresses. For those who have inherited undocumented software, this capability is as valuable as the refactoring itself.

AI-Driven Testing for Legacy Systems

When a migration change is made, a test generation model produces coverage for the affected components automatically. The coverage expands as the code changes, which means the test suite grows with the migration rather than lagging behind it. Regression gaps — the most common source of post-migration incidents — are addressed before deployment rather than discovered after.

That reduction in QA bottleneck has a measurable downstream effect. Incremental deployments become safer, release confidence increases, and the migration moves faster overall.

Legacy Application Modernization Best Practices

A project that is technically sound can still fail if the execution is poorly sequenced. The practices below address the most common points where projects lose momentum or build up avoidable fragility.

Start with a Modernization Audit

Every solution overhaul needs a baseline before any work begins. Without one, scope is estimated. Evidence replaces guesswork only after the audit is complete.

The audit covers four areas:

• A codebase review identifies technical debt and the dependency structure the migration has to work around. 
• An infrastructure assessment establishes what the current environment can support.
• A team capability review surfaces the skill gaps between maintaining the existing platform and building on a modernised one. 
• A process review identifies where current workflows will need to change as the stack evolves.

What the audit reveals often reframes the project entirely. Components assumed to be low-risk carry hidden dependencies. Infrastructure constraints rule out approaches that looked viable on paper. Starting without that clarity means discovering these obstacles mid-project. The cost of adjusting at that point is significantly higher.

Prioritise Business-Critical Modules First

Risk-weighted prioritisation is what separates a programme that delivers early value from one that runs for months without visible results.

The modules where failure is costliest are the right starting point. Revenue-critical components and compliance-sensitive data flows are where failure is costliest. Early stabilisation of those components protects the business while the rest of the migration proceeds. A phased migration approach ensures they are addressed and validated before broader work begins.

Before committing to full rollout, a proof of concept on the highest-risk module confirms the chosen approach holds under real conditions. That validation step is what makes subsequent phases predictable. Without it, the approach is unproven at the point where the stakes are highest.

Build in Automated Testing Early

A test harness set up before migration begins is what makes incremental changes deployable with confidence. The safety net that makes each deployment low-risk is automated regression testing, in place from the first migration stage.

Retrofitting tests after migration is consistently more expensive. The codebase has changed by that point, original behaviour is harder to verify, and coverage gaps surface through incidents. Each gap found in production costs more to resolve than one caught before deployment.

Setting up the test infrastructure early produces a compounding return. Each migration stage adds to the coverage baseline. By the time the final components are migrated, the test suite reflects full tool behaviour. Release confidence is built on evidence.

Document Before You Migrate

Documentation produced before migration begins serves three purposes that post-migration documentation cannot. It captures software behaviour while the people who understand it are still working with it. It gives incoming engineers a reference that makes onboarding faster. It creates an audit trail that supports compliance reviews throughout the process.

Skipping this step means encountering the cost at the worst possible moment.

A key engineer leaves mid-project. A compliance audit requires evidence of tool behaviour at a specific point in time. A new team member needs to make a change to a component no one has documented. Each situation is recoverable. Each recovery takes time that documentation would have prevented.

Communicate Progress to Non-Technical Stakeholders

Invisible progress is what costs engineering programmes stakeholder confidence. Framing incremental migration as visible milestones gives business owners a way to track the project. Technical detail stays with the engineering team.

Sprint reviews structured around business outcomes translate engineering progress into terms that matter to budget approvers. Reduced maintenance overhead and improved response times are concrete results stakeholders can evaluate. Transparency about liabilities follows the same principle. When stakeholders understand what exposure is being addressed and in what order, resourcing decisions become easier to make and easier to sustain.

Why Teams Choose Anyforsoft for Legacy Application Modernization

AnyforSoft has been delivering complex engineering projects for over 15 years. Legacy application modernization services at AnyforSoft are scoped around engineering depth, and that is what separates them from standard software consulting. Engagements stay accountable through delivery. The work is done when the modernized solution is in production and performing.

Full-Cycle Legacy System Audit

Every AnyforSoft engagement begins with a structured audit covering codebase, infrastructure, team capability, and process. Dependencies are mapped and structural constraints are identified before any approach is chosen. The output is a scoped, evidence-based plan that drives every subsequent decision.

AI-First Modernization Approach

AnyforSoft applies AI tooling across the full overhaul workflow. Scope analysis that would take weeks manually completes in a fraction of the time. On recent engagements, AI-assisted analysis has reduced scope review time significantly against manual-only baselines. Human judgement stays on the critical path throughout. The evidence those decisions rest on becomes more complete and more precise.

Cross-Platform and Cross-Stack Experience

AnyforSoft’s software product development background spans EdTech, media, fintech, and real estate. These are industries where inherited codebases carry both compliance constraints and high traffic demands. Working across Drupal, Python, React, and AWS, the teams understand how both greenfield and outdated tools behave under pressure. That breadth is what makes custom software development experience directly relevant. The engineering judgment that applies to building from scratch is the same judgment that identifies what is worth preserving in an overhaul.

Transparent Roadmap and Risk-Aware Delivery

Timelines stay visible through sprint-based delivery, which AnyforSoft uses across all projects. Scope adjustments remain possible at every stage. Business owners see progress as it happens. When scope needs to change, the impact is visible immediately and decisions can be made before cost accumulates.

Flexible Engagement Models

Two models are available depending on what the project requires. A dedicated development team takes full ownership of the programme, from audit through delivery. For organisations with internal engineering capacity, a team extension adds the specific expertise the in-house group needs. Both models operate on the same sprint-based structure with the same delivery visibility.

Delivered Projects, Measured Results

Inherited system projects look different depending on the industry, the stack, and the starting condition of the codebase. What each case shares is a measurable outcome and a production system that holds.

projektmagazin: CMS Migration for a High-Volume Editorial Platform

projektmagazin is Germany’s largest online portal for project management professionals. It serves over 100,000 monthly visitors and 25,000 subscribers. The platform was running on Drupal 6, which had reached end-of-life and stopped receiving security updates. With over 13,000 nodes and 13 content types, the migration had to preserve every content structure intact. Moving that volume without data loss was the core technical challenge.

AnyforSoft migrated the platform to Thunder CMS, a Drupal-based solution widely used in European publishing. Content was split into discrete migration segments. Custom process plugins handled format conversion where the new environment required it. Search was rebuilt on Elasticsearch and moved to a dedicated server for performance isolation.

The measured outcomes:

• 18% growth in website traffic
• 31% increase in website speed
• 10% growth in platform subscribers

AnyforSoft continues to maintain and support the platform. Uptime and security have remained stable as the subscriber base has grown.

Stage Entertainment: Platform Consolidation for Europe’s Largest Theatre Producer

Stage Entertainment operates more than 20 theatres across Europe and attracts over 10 million visitors annually. Regional websites ran independently on different technologies. Consistent content management was difficult, and every new show launch required a from-scratch build.

AnyforSoft delivered a Drupal-based multisite platform that brought all regional properties under one unified architecture. Centralised content management replaced fragmented workflows, and reusable components made new show launches significantly faster. With offline ticket sales constrained during the project period, the digital platform became the primary revenue channel.

Across a 2+ year collaboration, the results were:

• 5 websites developed and launched under one platform
• Faster show launches using reusable components
• Nomination for a digital impact award for the transformation

The platform continues to serve as the operational backbone for Stage Entertainment’s digital presence across regions.

Game Informer: Platform Reconstruction and Revenue Activation

Game Informer is one of the most recognised names in gaming media, with a publication history spanning 28 years. When the magazine shut down in 2024, the technical inheritance was a dated codebase, a partial database, and no subscriber base. The revival required complete platform reconstruction and immediate revenue generation simultaneously.

AnyforSoft rebuilt the platform, integrating Stripe for payment processing and MailerLite for subscriber communications. Paywall functionality was added to protect premium content. When the site relaunched, 5 million visitors hit the infrastructure simultaneously.

The business outcomes followed quickly:

• 26,000 subscribers acquired from zero at relaunch
• Revenue activated immediately through digital subscriptions and print sales
• 24-hour turnaround on promotional features during active campaigns

The collaboration is ongoing. New features continue to be developed as the subscriber base grows toward 30,000.

Pine Dev Studio: AWS Infrastructure Overhaul for a High-Load Application

Pine Dev Studio is a web agency whose client solution was running on an unstable AWS infrastructure. Unreliable connections between front-end and back-end components were causing data loss. Performance bottlenecks under load were generating critical errors, and no advanced backup system was in place.

AnyforSoft’s DevOps team restructured the entire AWS environment. Infrastructure was divided into dedicated backend, frontend, and database subnets. Load balancers were implemented on both sides. PostgreSQL replication was configured to eliminate data loss exposure.

Server performance improved by 24% and 123 performance errors were eliminated. The restructured infrastructure has handled high traffic loads without intervention since deployment.

CYBEX: Legacy Codebase Elimination and Platform Rebuild

CYBEX Ukraine is the regional representative of a global child safety products brand. Substantial amounts of dated JavaScript had accumulated, slowing performance and blocking new feature development. Running on Drupal 7 and approaching end-of-life, the solution was no longer compatible with modern security standards.

A direct migration was ruled out early. What had accumulated was too deeply integrated to carry forward without the performance problems following.

AnyforSoft rebuilt the platform from scratch on Drupal 9, eliminating the inherited code entirely. ERP integration was added for real-time inventory and pricing. Nova Post API enabled location-based checkout for customers across the region.

The rebuilt platform achieved green scores across all PageSpeed Insights metrics. AnyforSoft continues to provide maintenance and support.

About the Author

Eduard Grigalashvili

Technical Writer

Ed is a technical content writer with more than seven years of experience. He loves crafting compelling content that explains complex technology in ways that make it easy to understand.