Engineering Leadership · Infrastructure

Modernizing Legacy Infrastructure Without Breaking the Business.

Every CTO knows the system is held together by string and prayer. Fewer know how to replace it without triggering the outage that defines their tenure. This is the pragmatic playbook. 

There is a particular kind of silence that falls over an engineering team when someone finally says it out loud: "We have to replace this system." Everyone has known for years. Everyone has been quietly praying it would last one more quarter. The system in question — a 2007 monolith, a mainframe older than half the team, a Rails 3 app fused to a payments flow that nobody fully understands anymore — generates somewhere between most and all of the revenue.

So the question is never whether to modernize. The question is how to do it without becoming the cautionary tale told at the next CIO summit.

I've watched this play out from both sides — leading modernizations that worked, and inheriting ones that didn't. The teams that succeed are not the ones with the biggest budgets or the most talented engineers. They are the ones who internalize a single, uncomfortable truth: the system in production is not the enemy. The replacement plan usually is.

 

 

 

§ 01 — The Trap 

Why "Big Bang" Rewrites Keep Failing

The default instinct is seductive: freeze the old system, build a clean new one in parallel, flip the switch on a Sunday at 2 a.m., and wake up in the future. It is almost always wrong.

Big-bang rewrites fail because they make a bet that gets more expensive every month: that the business will not change while you spend 18 to 36 months rebuilding it. The business always changes. Regulations shift. A new payment method launches. A competitor moves. By month 14, the team is rebuilding a system that no longer exists.

 

The alternative, popularized by Martin Fowler, is the Strangler Fig pattern — named after the vine that gradually envelops a host tree until the tree is gone and the vine stands alone. New functionality is built alongside the legacy system. Traffic is routed slice by slice. The old system shrinks. One day, quietly, it is gone. Nobody has a cutover weekend. Nobody writes a postmortem.

The goal of modernization is not to ship a new system. It is to make the old system progressively less important — until removing it is uneventful.

 

§ 02 — The Playbook

Five Phases That Actually Work

Across the modernizations I've seen succeed, the shape is remarkably consistent. It is not glamorous. It is mostly discipline.

 

 

 

Phase 1 — Map the territory you actually have.

Before anything else: invest in understanding. Diagram every external dependency. Find every cron job, every shell script someone wrote in 2014, every undocumented API consumer. The single most common failure mode in modernization is discovering the dependency you didn't know existed three weeks before launch.

Phase 2 — Build a seam.

Introduce a layer of indirection — an API gateway, a façade service, an anti-corruption layer — between the legacy system and the rest of the world. This seam is the foundation for everything that follows. Without it, you cannot redirect traffic incrementally. With it, every subsequent change becomes reversible.

Phase 3 — Strangle the smallest valuable slice.

Resist the urge to start with the most important workflow. Start with one that is bounded, well-understood, and ideally a little boring. Ship it behind a feature flag. Route 1% of traffic. Then 5%. Then 50%. You are not trying to prove the new system works. You are trying to discover where it doesn't.

Phase 4 — Migrate data with dual writes and reconcile relentlessly.

Data migration is where modernizations most often die. Run dual writes — every transaction lands in both old and new systems. Build reconciliation tooling that compares outputs every hour. Do not trust the new system until you have weeks of clean diffs. This is unsexy work. It is also the work.

Phase 5 — Decommission deliberately.

Move the legacy system to read-only. Wait. Archive. Wait again. Then shut it down. The temptation to celebrate the cutover is enormous. Resist it. The win is the absence of incident, not the presence of a new logo on the architecture diagram.

You are not trying to prove the new system works. You are trying to discover where it doesn't.

 

§ 03 — The Comparison

Two Mental Models, Side by Side

To make the contrast concrete:

 

§ 04 — The Traps

Five Failure Modes I Keep Seeing

Even well-designed modernizations break in predictable ways. Watch for these.

1. Underestimating the data. The application is usually the easy part. The data — its shape, its history, the implicit business rules encoded in twenty years of edge cases — is the hard part. Budget for it accordingly.

2. Replacing the system, but not the assumptions. Teams sometimes rebuild a 2008 architecture with 2024 frameworks and call it modernization. If the new system encodes the same coupling and the same assumptions, you have rewritten the problem in a more expensive language.

3. Losing institutional knowledge. The engineer who has been there for fifteen years is the most valuable person on the project — not the cloud architect who joined last quarter. Treat them that way, in scope and in compensation.

4. Confusing motion with progress. "We migrated 40% of the services" is not the same as "we delivered 40% of the value." Pick metrics that map to business outcomes, not engineering activity.

5. Declaring victory too early. The legacy system is not gone when traffic stops flowing to it. It is gone when it is decommissioned, archived, and removed from the on-call rotation. Until then, you are running two systems, and you are paying for both.

 

 

Modernization is not a technical project. It is an exercise in organizational nerve — the discipline to move slowly when everyone wants speed, and quickly when everyone wants caution. The teams I've seen succeed are not the ones who built the most elegant new architecture. They are the ones who, three years later, can look back at the legacy system being quietly switched off and not remember the exact day it happened.

That is the goal. Not a cutover. A quiet ending.

 If you've led a modernization — successful or otherwise — I'd love to hear what you learned. The patterns get sharper when more people share scars.

 

 

Why IT and OT Convergence Is Accelerating.

A decade ago, the network closet and the factory floor lived on different planets. Today, they're sharing the same nervous system — and the gap between leaders and laggards is widening fast.

 

For most of the digital era, Information Technology (IT) and Operational Technology (OT) operated as two parallel universes that politely ignored each other.

IT lived in air-conditioned data centers, worrying about email outages, ERP rollouts, and whether someone clicked on a phishing link. OT lived in plants, refineries, substations, and warehouses, worrying about whether a pump kept spinning at 1,725 RPM.

They had different priorities (IT cared about confidentiality; OT cared about availability and safety), different vendors, different vocabularies, even different career paths.

That world is ending. Fast.

 

The classical IT/OT divide — and the unified stack that's replacing it. By 2030, this market is projected to triple, reaching $151B.

 

 

The global IT/OT convergence market was valued at roughly $75 billion in 2025 and is on track to reach $151 billion by 2030 — a 14.6% compound annual growth rate, according to The Business Research Company. By the end of 2025, more than 75% of leading manufacturers had already begun integrating IT and OT in some form.

This isn't a technology fashion. It's a structural shift — and the forces behind it are accelerating, not slowing down.

 

First, what do we actually mean by "convergence"?

Convergence doesn't mean "plug a PLC into your corporate VLAN and call it a day." It means three things stitched together:

1. Architectural integration — OT data flows into IT systems (data lakes, analytics platforms, ERP) in something close to real time, and IT systems can send context or commands back.
2. Operational alignment — engineering, operations, and IT teams share governance, runbooks, change processes, and incident response — instead of pointing fingers across an org-chart gap.
3. Security unification — one identity model, one set of policies, one observability layer covers both worlds.

When done well, it removes the seam between "the business" and "the process." When done badly, it creates an enormous, lightly-defended attack surface.

Both outcomes are happening right now in the wild — which is exactly why this topic matters.

Five years ago, "should we converge IT and OT?" was a strategic question worth debating. Today, it isn't. The forces driving convergence aren't going to reverse.

Why now? Seven forces past the point of no return

Convergence has been talked about for fifteen years. What changed is that several independent trends matured at the same time and started reinforcing each other. None of them alone would have flipped the switch. Together, they're irresistible.

 

Each driver has reached a threshold of maturity. The compounding effect is what makes 2025–2030 the inflection decade. 

 

1Industrial IoT became unavoidable

Industrial sensors got cheap, small, and standardized. The number of connected industrial devices is projected to exceed 29 billion globally by 2030. Once a piece of equipment is generating a continuous telemetry stream, the question isn't whether it will reach IT systems — it's how.

02Industrial AI demands operational data

AI is the loudest topic on every earnings call in the manufacturing sector — 44% of manufacturing CEOs discussed AI initiatives in Q4 2025 earnings calls, up 35% year over year, according to IoT Analytics. But industrial AI is almost worthless without OT data. You can't build a predictive maintenance model, a quality optimizer, or a yield forecaster from spreadsheets. AI is the demand signal. Convergence is the supply chain.

03Cybersecurity is no longer optional

As IT/OT systems connect, 75% of OT cyberattacks now begin as IT breaches. Ransomware attacks on OT systems jumped from 32% in 2023 to 56% in 2024. The industrial sector saw the sharpest increase of any sector in average breach cost in 2024 — up roughly $830,000 per incident.

04 Cloud + edge architectures finally make the math work

For years, "putting OT data in the cloud" was a non-starter — too much latency, too much cost, too much risk of losing autonomy on the plant floor. Modern hybrid architectures solved that. You can now keep deterministic control local and still benefit from elastic compute upstream.

05 Digital twins crossed the chasm

A digital twin is just a vivid use case for converged data. Organizations deploying them report operational efficiency gains around 20%, which is what gets budgets approved.

06 ESG made operational data a finance problem

Scope 1, 2, and increasingly Scope 3 emissions reporting requires granular, auditable data. That data doesn't live in finance systems. It lives in OT. Sustainability has quietly become one of the strongest mandates for IT/OT integration.

07 The workforce shift is forcing the issue

A generation of OT engineers is retiring. The engineers replacing them grew up with smartphones, GitHub, and dashboards. They expect remote access, modern tooling, APIs, and unified login. The old "isolated control room" model isn't just technologically out of date — it's culturally untenable.

· · ·

What you actually get: the value stack

When companies talk about "IT/OT convergence ROI," they often skip straight to "AI" or "digital transformation." But the value is layered. You can't skip levels

 

 

The value stack. Most organizations sit at Levels 1–2. The prize sits at Levels 4–5. The path between is what convergence delivers. 

 

 

The honest assessment: most organizations sit somewhere between Level 1 and Level 2. They have dashboards, maybe some predictive maintenance pilots. The prize — autonomous operations, equipment-as-a-service models, data monetization — sits at Level 4 and Level 5. The path between is exactly what convergence delivers.

 

 

The cybersecurity paradox

If there is one topic that deserves its own section, it's this one — because the same connectivity that makes convergence valuable also makes it dangerous.

The old security model for OT was elegant in its simplicity: air-gap everything. Don't connect the control network to the corporate network, don't connect it to the internet, and you don't have to worry about modern cyber threats.

That model is finished. Not because anyone decided to abandon it, but because reality moved past it. An estimated 70% of OT systems are now connecting to IT networks — driven by remote support contracts, vendor diagnostics, cloud-based historians, and the workforce trends mentioned above.

 

 The double-edged nature of convergence. The same connectivity creating risk is the only architecture in which unified defense becomes possible.

 

What's emerging in 2025–2026 is a new security architecture: hybrid models combining central visibility with local resilience, zero-trust microsegmentation enforcing granular boundaries between zones, and AI-augmented detection watching both IT and OT telemetry simultaneously.

If you're an IT or OT leader and you're not already at the table designing this together, you're already behind.

What's actually hard about it

I'd be doing a disservice if I made this sound easy. Convergence is genuinely difficult, and most failures trace back to a few predictable issues:

• Cultural mismatch. IT teams optimize for speed of change. OT teams optimize for stability and safety. Neither side is wrong. Both have to bend.
• Legacy systems and protocols. A typical industrial site is a museum of decades. Convergence doesn't mean ripping everything out; it means choosing the right abstraction layers (OPC UA, MQTT, unified namespace patterns).
• Skill gaps in both directions. Most IT pros don't know what a PLC scan cycle is. Most OT engineers don't know what an OAuth token is. Building hybrid teams matters more than buying any platform.
• The temptation to do everything at once. Convergence is a multi-year program, not a project. Start with one site, prove it out, then scale.

The strategic question is no longer if

Five years ago, "should we converge IT and OT?" was a strategic question worth debating.

Today, it isn't. The forces driving convergence — AI, IIoT, cybersecurity, cloud, digital twins, ESG, the workforce — aren't going to reverse. The market data is unambiguous: this is happening at every serious industrial company, and the gap between leaders and laggards is widening fast.

The real strategic question now is: how fast, how safely, and how well can your organization do it?

The companies that figure that out will dominate the next decade of industrial competition. The ones that don't will be acquired by companies that did.

Which one do you want to be?

 

 

 

Why Most Digital Transformations Fail at Execution

Every boardroom in 2026 has the same slide: "We are a digital-first company." Every CEO has the same conviction. And yet, year after year, the same uncomfortable statistic keeps surfacing — roughly 70% of digital transformation initiatives fail to achieve their stated objectives.

It's not for lack of ambition. It's not for lack of investment. Global spending on digital transformation crossed $3.4 trillion last year. Strategy decks are sharper than ever. Vendors are more mature. Cloud platforms are commoditized.

So what's actually breaking?

The answer, in almost every postmortem I've sat through, is the same: the strategy was sound, but the execution collapsed.

 

The execution gap is the real story

Notice what the chart above doesn't say. It doesn't say companies are picking the wrong cloud. It doesn't say they're choosing the wrong CRM. The strategy bucket is the smallest one.

The truth most leaders don't want to publish in a press release: transformations don't fail because the vision was wrong. They fail because the organization couldn't operationalize the vision.

Here are the five execution killers I see again and again. 

The five execution killers

1. Unclear ownership. Transformations are routinely "co-owned" by IT, operations, and a steering committee. Co-ownership is a synonym for no ownership. When everyone is accountable, no one is. The successful programs I've seen always have one named executive who lives or dies by the outcome.

2. Cultural resistance. Humans don't resist change; they resist loss. Loss of status, loss of expertise, loss of the workflow they spent a decade mastering. If your transformation roadmap doesn't include an honest conversation about what people are being asked to give up, expect quiet sabotage dressed up as compliance.

3. Tech-first thinking. "We're rolling out [platform X]" is not a transformation. It's a procurement event. The painful question — what business outcome will be measurably different, for whom, and by when? — gets skipped because picking a vendor feels like progress.

4. Change management as afterthought. A useful rule of thumb: for every dollar spent on the technology, plan to spend at least the same on change enablement. Training, communication, incentive redesign, role clarity. Most programs allocate a fraction of that and wonder why adoption stalls at 30%.

5. Measuring activity instead of outcomes. "We migrated 80% of workloads to the cloud" tells you nothing about whether the business got faster, cheaper, or more resilient. Output metrics give comforting dashboards. Outcome metrics give honest answers.

What the winners do differently

The 30% that succeed aren't smarter. They're disciplined about the things the 70% treat as soft.

 

 

They name a single owner. Not a committee. Not a "transformation office" with a dotted-line everywhere. One executive whose performance review and bonus are tied to the outcome.

They define outcomes before tools. Before a vendor is shortlisted, three numbers are written down: what gets measurably better, by how much, and by when. Every subsequent decision is tested against those three numbers.

They fund change like it's infrastructure. The training, the role redesign, the new incentive structures, the internal communications — all of it is budgeted from day one, not scraped together from leftover line items in year two.

They ruthlessly prioritize. The instinct of every transformation is to attack everything at once. Winners pick three battles. They finish those three. Then they pick three more. Programs that try to transform everything simultaneously transform nothing.

The uncomfortable truth for leaders

If you're three years into a transformation and the results feel softer than the announcement, the problem is almost certainly not your strategy deck or your technology choice. It's that your organization quietly absorbed the new tools into the old way of working.

Digital transformation is, in the end, an organizational design problem wearing a technology costume. The companies that will compound advantage over the next decade aren't the ones with the boldest vision — they're the ones with the discipline to execute against an ordinary one.

Strategy is a hypothesis. Execution is the experiment. And most experiments are failing because nobody bothered to set up the lab.

---

What's been your experience? Have you seen transformations succeed or fail for reasons different from the ones above? I'd love to hear your war stories in the comments.