The Third Category

Even the most basic carpenter plans before building. But sometimes the question isn't whether to build something new. It's whether to tear down a perfectly functional house and rebuild it in modern materials, on the same foundation, with the same floor plan, but using techniques that didn't exist when the original was built.

That used to be an obvious "no" most of the time. The original house works. The cost of rebuilding is enormous. The risk of getting it wrong is real. Why would you do it?

The answer used to be: rarely. Now the answer is: more often than you'd expect, and the reason isn't just AI getting faster. There's a deeper structural shift that I don't think has been named yet.

In the previous posts in this series, I covered greenfield projects (where AI compresses the build) and brownfield projects (where AI compresses the analysis). This post is about a project type that is structurally a hybrid of both, and that pre-AI was rarely committed to despite often being the right call.

The Project Type

Stack migration. Taking a working application built on an older technology and rebuilding it on a modern one, while preserving the existing data, the existing feature set, and the existing user expectations.

In the old economics, this was rarely committed to, and the reasons were not just engineering reasons. They were resourcing reasons.

A complete rewrite to a new tech stack required hiring people who specialized in that new stack. The team who knew the old system was rarely the team you would hire to build the new version. They understood the embedded business logic, the edge cases, why a particular calculation handled a particular scenario in a particular way. That knowledge sat with them, not with the developers who specialized in the new stack. So most rewrites involved replacing the team alongside replacing the code. That worked terribly. The new team rebuilt what they thought the old system did, not what it actually did, and the projects that survived this approach almost always did so by quietly bringing the original team back in some form.

I wrote about this years ago in Navigating ColdFusion Modernization: A Tale of Two Projects. The position was clear: complete rewrites almost always fail, and the path that actually works is phased modernization that preserves the original runtime, extracts business logic into APIs, and brings the existing team along. That was the right strategy for the resourcing reality of the time. The full rebuild was a path that most teams could not afford to take and most projects could not afford to lose.

I tackled a full rebuild years ago anyway. It took roughly a year. It was the right call. The resource constraint on the legacy stack had become acute. Continuing on the old technology meant a shrinking pool of developers we could hire, training overhead that grew each year, and a strategic ceiling on what the platform could become. The migration solved all of that. What made the decision hard was not whether the migration was worth doing. It was whether we could afford the timeline and the cost to do it. A year of engineering effort and a substantial budget commitment is a high bar, and many organizations facing the same situation chose to keep struggling rather than commit to that scale of project. The decision was defensible in hindsight, but committing to it in the first place required the kind of conviction that is hard to muster when the project will dominate a calendar year of engineering capacity.

That math has changed, and the reason it has changed is bigger than just AI getting faster.

The Real Unlock: Programming Language Is No Longer a Hiring Constraint

Programming language used to be a hiring problem. It is not anymore.

AI is, today, programming-language agnostic. Not becoming agnostic. Already agnostic. The same architect who's been thinking in ColdFusion for fifteen years can sit down with AI and produce equivalent Python, equivalent Go, equivalent TypeScript, equivalent whatever the target stack is, at production quality. The architect's understanding of the business logic is what matters. The translation to the new language is what AI handles, and AI handles it well.

This dissolves the central reason rewrites used to fail. The team that knows the system can now build the new version. They don't need to be replaced. They need to be augmented with AI, and they need to keep doing what they were already doing, which is making the architectural decisions that the AI then executes against.

That's the structural shift. Not "AI generates code faster." That's "AI made language expertise no longer a gating constraint on who can build the new system."

What This Looks Like in Practice

A recent migration I worked on took a monolithic legacy application and rebuilt it on a modern Python stack, including a database migration from SQL Server to PostgreSQL. The original application had been in production for over a decade, with all the accumulated decisions and edge cases that come with that kind of history. The migration is taking about three months. The code itself migrated to the new stack in weeks. The testing phase is what's eating most of the calendar, because validating that every feature works correctly on the new stack is exactly the kind of careful, surgical verification work that AI cannot fully automate. Planning also took meaningful time, because deciding on the new tech stack involved its own set of architectural decisions.

A year of work compressed into three months. That changes whether the project gets approved at all.

The constraint I have been working around for years on legacy modernization has been institutional knowledge, not cost. I wrote about this pattern several times before AI changed it. The phased approach in "Modernizing Without Rebuilding" and the case studies in "Navigating ColdFusion Modernization" were both responses to the same constraint: the team that knew the business logic was the team that knew the legacy language, and replacing the language meant stranding the knowledge. Hybrid was not just one option among many. It was often the only viable path.

AI changes this in two directions at once. It removes the language barrier so new developers can be hired into legacy stacks (the Real Unlock above). And it also lets the existing team safely migrate to a new stack without losing the business knowledge they hold, because the spec gets produced from the system they already understand. The earlier hybrid approach is still valid for many projects, and AI makes it faster. But the full migration option is now genuinely viable too. The choice between hybrid and full migration is no longer constrained by who can be hired or who will be lost. It is decided by what the situation actually calls for. I expanded on the AI-era version of this in "How AI Accelerates Legacy System Modernization."

Why It's Structurally a Hybrid

The reason I'm calling this out as a third category is that stack migration is structurally a hybrid of greenfield and brownfield, and the AI compression on it stacks accordingly.

The new codebase is greenfield in form. There's no existing code in the new stack to honor, no implicit conventions, no production behavior in the new system to preserve. That's greenfield-style compression on the build side. AI generates code in the new language from a spec at close to greenfield speed.

The existing system is the spec. The legacy application's behavior, data model, and feature set become the input that drives what the new system needs to do. That's brownfield-style compression on the analysis side. AI maps the legacy codebase, identifies the entities, traces the workflows, and produces the equivalent specification for the new stack at twenty times human speed.

One important caveat. The greenfield-style build compression on stack migration is conditional on the legacy logic being clear enough to produce a clean spec. Well-written legacy code makes the spec straightforward and the new build runs fast, with AI doing most of the work and the developer judiciously reviewing snippets. Poorly-written legacy code complicates the spec and forces the developer to do more work decoding the original before the rebuild can proceed cleanly. The compression is still real, just smaller, and the integration phase grows. The quality of what you are migrating from sets the ceiling on how fast you can migrate to the new stack.

Both compressions stack regardless. The analysis that used to take months happens in weeks. The build that used to take many more months happens in weeks. What's left is the integration and testing phase, which still requires experienced human judgment because the consequences of missing a behavior are real, and an automated test suite cannot fully cover a system whose original behavior was never fully documented.

This same pattern applies to other migration types. CMS platform migrations, where the content schema and editorial workflows of an existing system are ported to a new platform. Database engine migrations where the schema and query patterns transfer but the underlying technology changes. Framework upgrades that are large enough to constitute a rewrite. In all of these, the existing system serves as the spec, the new system is greenfield, and the AI compression stacks the same way it did on the Python migration.

The Skeptical Objection

If AI can port a decade-old application in weeks, doesn't that prove AI is replacing developers?

The answer is the same one this series has been making. The migration worked because a human still made the architectural decisions about the new stack. A human still validated each feature against expected behavior in the testing phase. A human still owned the cutover when the new system replaced the old one in production. AI accelerated the parts of the work that scale with effort, not the parts that scale with judgment.

What changed isn't whether developers are needed on a stack migration. What changed is who can do the work and whether the migration itself is worth doing. The team that knew the old system can now build the new one without a year of retraining or a wholesale replacement. That dissolves a constraint that used to kill these projects before the engineering even started. And projects that were dead on arrival in the old economics are now viable, because both the resourcing barrier and the cost barrier dropped at the same time. That's a different kind of unlock than "AI got faster." That's "AI made an entire category of work financially and organizationally defensible for the first time."

A Scoping Note for Practitioners

Stack migrations need to be priced against the new economics, not the old ones.

A migration that used to take a year and now takes three months is not just a faster project. It is a different category of project, with different ROI math, different risk profile, and different decision criteria for whether to do it at all. Clients still operating on pre-AI estimates for migration work will either reject viable projects because they look too expensive, or accept proposals that underprice the testing and integration phase where the real risk lives. Both outcomes are bad.

The honest scoping is short on the build, generous on the testing, and explicit about the cutover. The build phase is where the dramatic compression happens and where the engagement should look surprisingly fast. The testing and cutover phases are where the real risk lives, and they should be priced and timed accordingly. Compressing them in the proposal to make the project look more attractive is a mistake clients will pay for in production incidents.

The Closing Thought for This Post

Expect to see a lot more of this kind of project. The backlog of legacy systems waiting for modernization is enormous, and the cost barrier just dropped by a factor of three or four, while the resourcing barrier essentially disappeared. Stack migration is going to be one of the busier corners of the next several years of enterprise software work.

The teams that capture that work will be the ones who understand that the dramatic compression is real but bounded. The build accelerates. The architecture decisions don't. The testing doesn't. The cutover doesn't. The architect mindset matters as much on a stack migration as it does on a greenfield build. Probably more, because the legacy system carries decades of consequences for getting it wrong.

The next and final post in this series pulls everything together. The head-to-head comparison across all three project types. The full scoping framework. And the position I have arrived at after a year of working with AI on real client projects: AI has changed almost everything about how the work gets done, and it is not ready to replace the people doing it.