Technical debt is one of the most misunderstood concepts in software development. Teams use it to justify rewrites that never happen. Managers hear it as an excuse for slow delivery. Engineers feel it as the friction that makes every change harder than it should be.
But technical debt isn't inherently bad. Like financial debt, it's a tool. Used strategically, it accelerates delivery. Left unmanaged, it compounds until your codebase becomes unmaintainable.
This guide covers everything engineering teams need to know about technical debt: what it actually is, what causes it, how to measure it, when to pay it down, and how to prevent it from accumulating in the first place.
What Is Technical Debt, Really?
Ward Cunningham coined the term "technical debt" in 1992 to explain to non-technical stakeholders why software sometimes needs rework:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."
The metaphor is powerful because it captures something true: shortcuts have costs, and those costs compound over time.
But the metaphor has also been stretched beyond usefulness. Not every imperfection in code is "debt." Not every refactoring is "paying down debt." To manage technical debt effectively, you need a clearer definition.
Technical debt is the implicit cost of future rework caused by choosing an expedient solution over a better approach that would take longer.
Key elements:
- Implicit cost: The debt isn't visible in your issue tracker. It's hidden in slower development, more bugs, and harder onboarding.
- Future rework: Debt creates work you'll eventually have to do. You're not avoiding work; you're deferring it.
- Expedient solution: Debt is created by conscious or unconscious tradeoffs. You chose faster over better.
- Better approach exists: If there's no better approach available, it's not debt - it's just the state of the art.
What Technical Debt Is Not
Not all bad code is debt. Code can be poorly written without creating future rework costs. An ugly but isolated function that nobody needs to change isn't debt - it's just ugly.
Not all complexity is debt. Some problems are genuinely complex. The code that solves them will be complex too. That's not debt; that's appropriate complexity.
Not all old code is debt. Legacy code that works reliably and rarely needs changes isn't costing you anything. Leave it alone.
Not all missing features are debt. "We should add caching" isn't debt unless the absence of caching is causing problems that will require rework to fix.
Being precise about what constitutes debt helps you focus on what actually matters: the code that's actively slowing you down.
The Four Types of Technical Debt
Martin Fowler's technical debt quadrant provides a useful framework for categorizing different types of debt:
1. Deliberate and Prudent
"We know this isn't the best approach, but we need to ship by Friday. We'll refactor next sprint."
This is debt taken on consciously, with a plan to repay it. It's strategic - you're trading future work for current speed. This is often the right choice when:
- Time-to-market matters more than code quality
- You're validating an idea that might not survive
- The scope of the debt is contained and understood
The danger: "next sprint" never comes. Deliberate debt requires deliberate repayment.
2. Deliberate and Reckless
"We don't have time for good architecture. Just ship it."
This is debt taken on consciously without a plan to repay it. It's reckless because you're knowingly creating future problems without accounting for them. This happens when:
- Teams are under unrealistic pressure
- Leadership doesn't understand the tradeoffs
- Nobody expects to maintain the code long-term
This debt compounds fastest because it's often structural - affecting architecture, not just implementation.
3. Inadvertent and Prudent
"Now that we've built it, we understand how we should have built it."
This is debt you didn't know you were taking on. You made the best decisions you could with the information you had. Later, you learned better approaches. This is unavoidable in software development because:
- Requirements evolve as you build
- You learn about the domain through implementation
- New tools and patterns emerge
This debt is natural and healthy. The key is recognizing it when it appears and addressing it before it compounds.
4. Inadvertent and Reckless
"What's dependency injection?"
This is debt created through ignorance. The team didn't know better approaches existed. This happens when:
- Junior developers work without guidance
- Teams don't invest in learning
- Knowledge isn't shared across the organization
This debt is often the most expensive because it's pervasive. The team keeps making the same mistakes until someone intervenes.
What Causes Technical Debt?
Understanding the causes helps you address debt at its source rather than just treating symptoms.
Time Pressure
The most common cause. Deadlines create pressure to cut corners. Features ship with known issues because "we'll fix it later." The fix never happens because there's always another deadline.
Time pressure isn't inherently bad - constraints can drive creativity and focus. The problem is when pressure becomes chronic and debt accumulates without acknowledgment.
Changing Requirements
Requirements evolve. Code that was well-designed for the original requirements becomes awkward as the product changes. This is unavoidable in iterative development.
The debt accumulates when teams keep patching old code instead of rearchitecting for new requirements. Each patch adds complexity until the code becomes incomprehensible.
Lack of Knowledge
Teams make suboptimal decisions because they don't know better. This includes:
- Not knowing language or framework idioms
- Not understanding design patterns
- Not knowing about existing libraries that solve the problem
- Not understanding the domain deeply enough
This debt is addressable through learning, code review, and mentorship.
Poor Communication
Different parts of the codebase drift apart when teams don't communicate. Module A makes assumptions about Module B that become invalid. Integration points become brittle.
This is especially common in larger organizations where different teams own different services. Each team optimizes locally without considering system-wide implications.
Deferred Maintenance
Maintenance tasks that slip through the cracks:
- Dependency updates that fall behind
- Dead code that accumulates
- Documentation that drifts from reality
- Test coverage that erodes
Each deferred task is small. Collectively, they create an environment where change is risky and slow.
Architectural Shortcuts
Shortcuts that affect structure rather than implementation:
- Skipping abstraction layers to save time
- Hard-coding values that should be configurable
- Tight coupling between components that should be independent
- Choosing inappropriate data structures or patterns
Architectural debt is the most expensive kind because it affects everything built on top of the architecture.
Outdated Dependencies
Dependencies that fall behind create several kinds of debt:
- Security vulnerabilities from unpatched code
- Compatibility issues with other libraries
- Missing features that require workarounds
- Increasing upgrade difficulty as versions pile up
The longer you wait, the harder the upgrade becomes.
Common Technical Debt Patterns
Recognizing debt patterns helps you identify issues before they become crises.
The God Object
One class or module that does everything. It started small but grew because adding functionality there was easier than creating new modules. Now it's thousands of lines long, understands every part of the system, and every change risks breaking something.
Signs you have it:
- One file that everyone has to modify
- Merge conflicts constantly
- Nobody fully understands what it does
- Tests for it are slow and brittle
The fix: Gradually extract responsibilities into focused modules. Use the strangler pattern - don't rewrite, extract.
Copy-Paste Inheritance
Similar code duplicated across the codebase because copying was faster than abstracting. Now when you fix a bug, you have to remember to fix it in five other places.
Signs you have it:
- Bug fixes that require changes in multiple files
- "Almost identical" code blocks scattered around
- Developers asking "where else does this pattern appear?"
The fix: Identify the variations, create an abstraction that handles them, consolidate the copies. Or use automation:
@devonair identify all instances of the getUserPermissions pattern and consolidate them into a single implementation
Lava Layer Architecture
Layers of dead or dying architectural patterns, each added by a different team or era. The REST API wraps the SOAP API wraps the direct database calls. Nobody removes the old layers because something might still use them.
Signs you have it:
- Multiple ways to do the same thing
- "Legacy" and "new" versions of services
- Developers unsure which approach to use for new code
- Configuration for systems that might be deprecated
The fix: Audit what's actually used. Remove dead paths. Standardize on one approach and migrate remaining uses.
Dependency Hell
Dependencies that conflict, require specific versions, or haven't been updated in years. The build only works on certain machines. Updating one package breaks three others.
Signs you have it:
- "Works on my machine"
- Pinned versions with comments like "DO NOT UPDATE"
- Security scanners flagging known vulnerabilities
- New developers spending days getting the build to work
The fix: Systematic dependency updates with testing. Address conflicts one at a time. Use automation to keep dependencies current:
@devonair schedule weekly: update patch-level dependencies and run full test suite
Test Debt
Tests that are flaky, slow, or missing entirely. The test suite can't be trusted, so developers stop running it. Bugs ship because nobody caught them.
Signs you have it:
- Tests that fail randomly
- Tests skipped or commented out
- Low coverage in critical paths
- Manual testing before every release
- "The tests are broken but the code works"
The fix: Delete flaky tests or fix them. Don't allow skipped tests to accumulate. Prioritize coverage for high-risk code. Make the test suite fast enough to run frequently.
Documentation Rot
Documentation that describes how the system worked months or years ago. New developers follow outdated instructions and waste hours. The team stops trusting documentation and relies on tribal knowledge.
Signs you have it:
- README examples that don't work
- API docs for deprecated endpoints
- Setup instructions that skip steps
- New developers always asking the same questions
The fix: Documentation as code - update docs in the same PR as code changes. Automate what you can:
@devonair on PR: if files in /src/api changed, verify the API documentation is still accurate
Configuration Sprawl
Configuration scattered across environment variables, config files, hard-coded values, and database tables. Nobody knows where a setting lives or what it does.
Signs you have it:
- "Where is that configured?" is a common question
- Settings duplicated in multiple places
- Unclear which settings affect which environments
- Production incidents from misconfiguration
The fix: Centralize configuration. Document every setting. Validate configuration at startup. Remove unused settings.
The True Cost of Technical Debt
Technical debt costs money, but the costs are hidden. They show up as:
Slower Development
The most direct cost. Every feature takes longer because developers have to:
- Understand convoluted code before changing it
- Work around existing problems
- Fix breakages caused by brittle code
- Test manually because automated tests don't exist or don't work
Teams often don't realize how much debt is slowing them down because the slowdown is gradual. They've normalized working in a difficult codebase.
More Bugs
Debt-laden code has more bugs because:
- Complex code is harder to reason about
- Missing tests mean bugs ship to production
- Workarounds create edge cases
- Developers make changes they don't fully understand
Bug fixes take longer too, because understanding the root cause requires understanding the tangled codebase.
Developer Frustration
Working in a difficult codebase is demoralizing. Developers want to do good work, but the codebase fights them at every turn. This leads to:
- Lower job satisfaction
- Higher turnover
- Difficulty hiring (word gets around)
- Burned-out engineers who stop caring
The human cost of technical debt is often underestimated. Morale matters.
Knowledge Silos
When code is hard to understand, only the people who wrote it can work on it. This creates:
- Bus factor risk (what if they leave?)
- Bottlenecks (only one person can fix this)
- Slow onboarding (new developers can't contribute)
Knowledge silos compound debt because the people who understand the code don't have time to document it - they're too busy fixing things.
Opportunity Cost
The biggest cost is invisible: the features you didn't build because you were fighting debt. While your team struggles to ship basic functionality, competitors are innovating.
Technical debt is a tax on every feature. The higher the tax, the less you can afford to invest in growth.
How to Measure Technical Debt
You can't manage what you can't measure. But measuring technical debt is tricky because most of the cost is implicit.
Code Metrics
Automated tools can measure code quality indicators:
Cyclomatic complexity: How many paths through the code? High complexity correlates with bugs and difficulty understanding.
Code duplication: How much copy-pasted code exists? Duplication means changes need to happen in multiple places.
Test coverage: What percentage of code is tested? Low coverage means more manual testing and more production bugs.
Dependency freshness: How outdated are your dependencies? Old dependencies mean security risks and upgrade difficulty.
Linting violations: How many style and pattern violations? Many violations suggest rushed or careless code.
These metrics are proxies, not direct measures of debt. High complexity isn't necessarily debt if the problem is genuinely complex. Low test coverage isn't debt if the code never changes.
Use metrics as signals, not absolute measures.
Time Metrics
Track how long things take:
Cycle time: How long from starting work to shipping? Increasing cycle time suggests accumulating friction.
Bug fix time: How long to diagnose and fix bugs? Increasing fix time suggests code is getting harder to understand.
Onboarding time: How long before new developers contribute? Long onboarding suggests the codebase is hard to learn.
Deployment frequency: How often can you ship? Decreasing frequency suggests increasing fear of change.
Compare these metrics over time. Worsening trends indicate accumulating debt.
Developer Surveys
Ask the people who work in the code:
- What parts of the codebase do you dread working in?
- What takes longer than it should?
- What would you refactor if you had time?
- What breaks unexpectedly?
Developers know where the debt is. Their frustration is a leading indicator of problems.
Debt Inventory
Maintain a list of known debt items:
@devonair identify technical debt in /src and create a prioritized list
For each item, estimate:
- Impact: How much does this slow us down?
- Risk: What could go wrong if we don't fix it?
- Effort: How hard is it to fix?
Prioritize by impact and risk relative to effort. High-impact, low-effort fixes should happen first.
When to Pay Down Technical Debt
Not all debt needs to be paid down. Some debt is cheap to carry. Some debt is in code you'll never touch again. Paying down debt has opportunity cost - that time could be spent on features.
Pay Down Debt When...
The debt is in code you change frequently. If you're constantly working around a problem, fix it. The investment will pay off quickly.
The debt is blocking important work. If you can't build Feature X without first fixing Problem Y, fix Problem Y.
The debt is creating bugs. Customer-facing quality problems demand attention. Fix the source, not just the symptoms.
The debt is a security risk. Outdated dependencies with known vulnerabilities need immediate attention.
The debt is affecting morale. If developers are frustrated and turnover is increasing, debt reduction is an investment in your team.
Leave Debt Alone When...
The code is stable and rarely changes. Ugly code that works and nobody touches isn't costing you anything.
The fix is more complex than living with the debt. Sometimes the cure is worse than the disease.
You're going to replace it soon anyway. Don't polish code that's scheduled for deletion.
The debt is contained. A mess that stays in one place is better than spreading the mess by refactoring badly.
The Campsite Rule
A practical middle ground: leave code better than you found it.
When you work on a file, fix small issues you encounter. Add a missing test. Clean up a confusing function. Update an outdated comment.
You're not paying down all debt at once. You're making incremental improvements in the areas you're already working on. Over time, frequently-touched code gets cleaner.
Strategies for Paying Down Debt
The Boy Scout Rule
"Always leave the code better than you found it."
Make small improvements as part of regular work. No dedicated "debt sprint" needed. The codebase improves continuously as a byproduct of feature development.
This works well for superficial debt: naming, small refactors, missing tests. It doesn't address architectural debt or large-scale cleanup.
Dedicated Debt Sprints
Reserve time specifically for debt reduction. Some teams use:
- 20% time: One day per week for maintenance
- Debt sprints: One sprint per quarter for cleanup
- Rotation: One developer on debt duty while others do features
The advantage: debt gets explicit attention. The disadvantage: it can feel like punishment, and business pressure often cancels debt sprints.
Strangler Pattern
Gradually replace problematic code by wrapping it in a new implementation:
- Write new, clean code alongside the old
- Route new features through the new code
- Gradually migrate existing functionality
- Delete the old code when it's no longer used
This works well for architectural debt where you can't rewrite everything at once. The system keeps working while you gradually improve it.
Refactoring with Coverage
Before refactoring, ensure tests cover the code:
- Add tests to characterize current behavior
- Refactor the implementation
- Verify tests still pass
This is safer than refactoring untested code but requires investment in test coverage first.
Automated Debt Reduction
Use automation for mechanical debt reduction:
@devonair remove all unused imports across the codebase
@devonair update all deprecated API calls to use the new patterns
@devonair schedule weekly: fix any new lint violations
Automation handles the tedious parts of debt reduction - the find-and-fix work that's important but mind-numbing for humans.
Preventing Debt Accumulation
The best debt is debt you never take on. Prevention is cheaper than remediation.
Code Review
Catch debt before it merges:
- Enforce standards and patterns
- Question shortcuts and workarounds
- Ensure tests accompany new code
- Share knowledge about better approaches
Code review is your primary defense against inadvertent debt from lack of knowledge.
Architecture Reviews
Review significant changes before implementation:
- Does this fit the existing architecture?
- Are we taking on debt knowingly?
- What are the alternatives?
- If we're taking debt, when will we repay it?
Catching architectural debt early prevents expensive rework later.
Testing Culture
Teams that test have less debt:
- Tests document expected behavior
- Tests catch regressions before they ship
- Tests make refactoring safe
- Testable code is often better-designed code
Invest in testing infrastructure and culture.
Documentation
Maintain documentation that stays current:
@devonair on PR: if API endpoints changed, update the API documentation
Good documentation reduces "accidental" debt where developers make incorrect assumptions about how code works.
Dependency Management
Stay current with dependencies:
@devonair schedule weekly: update all patch-level dependencies
@devonair schedule monthly: report on available minor and major updates
Small, frequent updates are easier than large, infrequent ones.
Refactoring as You Go
Normalize refactoring as part of feature work:
- Refactor before adding new code (make room for the change)
- Refactor after adding new code (clean up what you learned)
- Include refactoring time in estimates
When refactoring is normal, debt doesn't accumulate.
Communicating About Technical Debt
Engineering teams often struggle to communicate debt to non-technical stakeholders. The financial metaphor helps, but it needs context.
Speak in Business Terms
Don't say: "The authentication module has high cyclomatic complexity."
Do say: "Adding new authentication methods takes three times longer than it should because of how the code is structured. Fixing this would make future security features faster to build."
Connect debt to business outcomes: speed, cost, risk, opportunity.
Quantify When Possible
Don't say: "We have a lot of technical debt."
Do say: "We estimate that technical debt is adding 30% to our development time. Addressing the top three issues would cost two weeks and recover that time within a quarter."
Numbers make the conversation concrete.
Track Debt Explicitly
Maintain a visible debt inventory. When debt is tracked, it's harder to ignore. When it's visible to stakeholders, it becomes part of planning conversations.
Propose Solutions, Not Just Problems
Don't just complain about debt. Come with a plan:
- What debt should we address?
- How long will it take?
- What will we gain?
- How does this compare to feature work?
Make it easy for stakeholders to say yes.
Building a Sustainable Codebase
The goal isn't zero debt - it's sustainable debt. A level of debt you can carry without slowing down.
Set Quality Standards
Define what "good enough" looks like:
- Code review requirements
- Test coverage thresholds
- Documentation expectations
- Performance budgets
Standards prevent debt from creeping in through a thousand small compromises.
Make Quality Visible
Track and display quality metrics:
- Test coverage dashboards
- Code quality scores
- Dependency freshness
- Bug rates
What gets measured gets managed. Visible quality becomes organizational priority.
Invest in Tooling
Good tools reduce debt:
- Linters catch issues before commit
- Formatters eliminate style debates
- CI/CD enables frequent, safe deployments
- Automation handles mechanical maintenance
Every hour spent on tooling saves many hours of manual work.
Allocate Time for Maintenance
Explicitly budget time for maintenance:
- Reserve capacity for debt reduction
- Include maintenance in sprint planning
- Celebrate maintenance work like feature work
If maintenance is always deprioritized, debt will always accumulate.
Learn from Debt
Every significant debt item is a learning opportunity:
- Why did this happen?
- Could we have prevented it?
- What should we do differently?
Teams that learn from debt create less of it over time.
The Debt Paydown Playbook
A practical framework for addressing debt systematically.
Step 1: Inventory Your Debt
You can't manage what you don't know about. Create a debt inventory:
-
Gather input from the team: Ask developers where they feel friction. What code do they dread working in? What takes longer than it should?
-
Review metrics: Look at bug rates by module, code complexity scores, test coverage, deployment frequency.
-
Audit dependencies: How outdated are they? Any known vulnerabilities?
-
Check documentation: Is it accurate? Complete? Does anyone use it?
Use automation to assist:
@devonair analyze the codebase and identify potential technical debt - unused code, high complexity, outdated patterns
Step 2: Categorize and Prioritize
Not all debt is equal. Categorize each item:
By type:
- Architectural (expensive to fix, high impact)
- Implementation (moderate effort, moderate impact)
- Superficial (easy to fix, low impact)
By location:
- Hot spots (code that changes frequently)
- Cold spots (code that rarely changes)
- Critical paths (code that affects core functionality)
By risk:
- Security risk (vulnerabilities, exposed data)
- Stability risk (likely to cause outages)
- Velocity risk (slows down development)
Prioritize debt that's in hot spots, affects critical paths, or creates significant risk. Ignore debt in cold spots that works reliably.
Step 3: Create a Paydown Plan
For high-priority debt, create concrete plans:
- What: Specific changes needed
- Why: Business impact if addressed vs. left alone
- How: Technical approach
- When: Timeline and resources required
- Success criteria: How you'll know it's fixed
Plans make debt actionable. Without plans, debt stays in the "someday" pile forever.
Step 4: Allocate Resources
Decide how you'll fund debt paydown:
Percentage allocation: Reserve 10-20% of capacity for maintenance. Consistent, predictable, sustainable.
Debt sprints: Dedicate entire sprints to debt periodically. Intensive but can feel like punishment.
Boy Scout rule: Improve code as you touch it. Organic but won't address architectural debt.
Automation: Handle mechanical debt with AI agents. Efficient for pattern-based cleanup:
@devonair schedule weekly: remove unused imports and dead exports
@devonair schedule monthly: update all minor-level dependencies
Most teams use a combination. Automation handles ongoing maintenance, percentage allocation addresses targeted improvements, and occasional focused sprints tackle larger architectural issues.
Step 5: Execute and Track
Track debt paydown like any other work:
- Create tickets/issues for debt items
- Include debt work in sprint planning
- Measure progress (items resolved, metrics improved)
- Celebrate wins
Make debt visible. When the team sees progress, motivation increases.
Step 6: Prevent Recurrence
After paying down debt, prevent it from returning:
- Update coding standards based on what you learned
- Add automated checks to catch similar issues
- Document decisions and patterns
- Schedule recurring maintenance
Debt reduction without prevention is a treadmill. You'll be back in the same place in a year.
Technical Debt and Automation
Many debt-reduction tasks are mechanical: finding all usages of a deprecated API, updating import patterns, removing dead code. These tasks are important but tedious.
AI automation changes the economics of debt reduction. Tasks that weren't worth the human time become practical when automated.
@devonair identify all uses of the deprecated authentication API and update them to use the new OAuth module
@devonair schedule weekly: remove unused imports and dead code
@devonair analyze the codebase and list the top 10 technical debt issues by estimated impact
Automation handles the mechanical work. Humans focus on judgment calls: which debt matters, how to restructure architecture, what patterns to follow.
The combination of human judgment and AI execution makes debt reduction practical at a scale that wasn't possible before. Maintenance that would take weeks happens in hours. Debt that was "too expensive to fix" becomes affordable.
Conclusion
Technical debt is inevitable in software development. Requirements change, knowledge evolves, and deadlines create pressure. The goal isn't to eliminate debt - it's to manage it intentionally.
Understand what you're dealing with. Not all bad code is debt. Focus on code that's actively slowing you down.
Measure what matters. Track code metrics, development velocity, and developer sentiment. Watch for worsening trends.
Pay down debt strategically. Address high-impact debt in frequently-changed code. Leave stable, isolated debt alone.
Prevent accumulation. Code review, testing, and documentation stop debt at the source. Automation handles ongoing maintenance.
Communicate clearly. Connect debt to business outcomes. Quantify costs and benefits. Propose solutions.
A healthy codebase isn't one without debt - it's one where debt is understood, tracked, and managed. Where the team makes conscious choices about tradeoffs. Where maintenance happens continuously, not in crisis-driven bursts.
That's the codebase your team deserves to work in. Start building it today.
FAQ
How do I convince leadership that technical debt matters?
Connect debt to metrics leadership cares about: delivery speed, bug rates, developer retention, security risk. Quantify the cost where possible. Propose specific investments with clear returns, not vague requests for "cleanup time."
Should we stop all feature work to pay down debt?
Rarely. Stopping feature work creates business pressure that often results in the debt sprint being canceled. Better approaches: allocate consistent percentage of time to maintenance, address debt in the areas you're already working on, or use the strangler pattern to gradually replace problematic code while continuing feature work.
How much debt is too much?
There's no universal threshold. Watch for symptoms: cycle time increasing, bug rates rising, developers frustrated, onboarding taking longer. If trends are worsening, you're accumulating debt faster than you're paying it down.
What if we inherited a codebase full of debt?
Start by understanding what you have. Identify the highest-impact issues. Focus on the code you need to change most frequently. Use the strangler pattern for architectural issues. Don't try to fix everything at once - prioritize ruthlessly.
How do I get developers to care about debt?
Most developers already care - they feel the pain daily. Give them time and permission to address issues. Celebrate maintenance work like feature work. Make quality visible and part of team goals. Remove pressure that forces shortcuts.
What's the difference between refactoring and paying down debt?
Refactoring is changing code structure without changing behavior. Paying down debt is addressing decisions that are costing you. They overlap but aren't identical. You might refactor code that isn't debt (improving already-good code). You might pay down debt without refactoring (updating dependencies, adding tests).
How do I know if a rewrite is justified?
Rewrites are rarely the answer. They're expensive, risky, and often end up recreating the same problems. Consider a rewrite only if: the existing code can't be incrementally improved, the business context has changed so fundamentally that the current architecture can't support it, and you have the resources to maintain two systems during transition. Usually, the strangler pattern is safer than a full rewrite.