Your 90-day plan
Legacy monolith
It pays the bills, nobody understands all of it, and every change feels risky.
Illustrative situation (fictional)A ten-year-old application with one large database that reports, scheduled jobs and other tools also depend on.
Days 1–30
Listen and map
FocusLearn what the system really does before judging how it does it.
Actions
- Trace the three business flows that matter most, from request to database and back.
- List everything else that reads or writes the database: reports, scheduled jobs, other applications.
- Ask each engineer which part of the code they avoid, and why.
- Ask the seniors what they would teach first if they had the time.for your team
- Read the pipeline: what runs, how long it takes, and what people skip.for your release process
Why
When a system already works, the first job is not to break what earns the money. A map of real flows shows where change is cheap and where it is dangerous.
Risk to avoid
Promising a modernization roadmap before you have the map.
Signals to watch
- You can explain the three main flows without reading your notes.
- The areas people avoid are written down, each with an owner.
Days 31–60
Earn trust with small, safe wins
FocusMake the next change safer, not the whole system newer.
Actions
- Find a seam in one busy flow and put tests around it that pin down today's behavior.
- Add logging or alerts to that flow, so a bad change shows up before users report it.
- Agree on a review checklist for changes that touch the database schema.
- Pair a senior with an early-career engineer on the first win, with the junior at the keyboard.for your team
- Make fixing a broken build the team's first priority, and cut the slowest step.for your release process
Why
Small wins that lower risk buy the credibility a bigger change will need later. Seams let you test legacy code without rewriting it first.
Risk to avoid
Refactoring for taste in code that is not on the critical path.
Signals to watch
- The busiest flow has tests, and they run on every change.
- The monolith's change fail rate holds steady or improves while this work lands.
Days 61–90
Commit to a direction
FocusPropose one strangler-fig slice with a clear exit, not a rewrite.
Actions
- Pick one well-bounded capability and route it to a new component beside the monolith.
- Write the decision down: what moves, what stays, and how you roll back.
- Share the map and the slice plan with the people who depend on the system.
- Rotate review duty so knowledge and approval rights spread beyond the seniors.for your team
- Shrink the batches: release more often, with fewer changes in each release.for your release process
Why
Gradual replacement spreads cost and risk over time and shows value early. A written rollback path makes the proposal easy to say yes to.
Risk to avoid
Running old and new paths side by side for longer than planned.
Signals to watch
- The first slice serves real traffic and can be switched back.
- People who depend on the system can explain the plan in one sentence.
- Deployment frequency rises while change fail rate holds steady.
What to leave alone at first
The rewrite debate. A big-bang rewrite is the most expensive way to learn what the old system actually does.
Grounded in practice from the CV
These are the CV lines this plan draws on. They show where the habits come from; they are not results promised for your team.
- Modernizing a legacy system
Leading the modernization of the company's internal workflow and HR platform, replacing a legacy web-forms system with a modern web application, API, and a new workflow engine.
DIGITURK · Dec 2023 - Present - Security hardening and performance testing
Drove security hardening and performance testing across legacy and modern systems, and introduced tooling that scaffolds new workflow modules.
DIGITURK · Dec 2023 - Present - Day-to-day delivery and code reviews
Led the development team's day-to-day delivery and code reviews.
MAKDOS · Aug 2020 - Oct 2023
Sources
General leadership and delivery practices come from these published sources. Each phase cites the ones it relies on.
- Picking the Right Transition Strategy (opens in a new tab)Michael D. Watkins · Harvard Business Review · 2009 · may require a subscription
The STARS situations (start-up, turnaround, accelerated growth, realignment, sustaining success) and why a new leader should match the plan to the situation.
- Why you must move fast to get the right team in place (opens in a new tab)Michael Watkins · I by IMD · 2022
Free to read. Names the five STARS situations; set a deadline for the significant team decisions of year one; the more severe the problems, the faster and deeper the changes.
- Legacy Seam (opens in a new tab)Martin Fowler · martinfowler.com · 2024
A seam, after Michael Feathers, is a place to alter behavior without editing in that place: the way to get legacy code under test.
- DORA’s software delivery performance metrics (opens in a new tab)DORA · dora.dev
Change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, measured per application or service and used to improve over time rather than to compare teams.
- Capabilities: Continuous integration (opens in a new tab)DORA · dora.dev
Merge small batches into trunk at least daily, keep automated tests to a few minutes, and fix a broken build before any other work.
- Strangler Fig (opens in a new tab)Martin Fowler · martinfowler.com · 2024
Replace a legacy system gradually, with new parts built beside it, instead of a big-bang rewrite.