One of the easiest mistakes in software modernization is also one of the oldest.
We take an existing process, application, or workflow and ask how to reproduce it with newer technology.
A manual procedure becomes a computer program.
A DOS program becomes a Windows application.
A Windows application gets a web interface.
The web application gets squeezed onto a phone.
And now we can hand an old codebase to an AI and ask it to rebuild the whole thing using a modern framework.
Every step can be technically successful.
But every step can still be the wrong thing to do.
There's an old expression I've used for more than forty years for this:
Don't pave the cow paths.
If the route was wrong to begin with, paving it doesn't make it right.
It just makes the wrong route faster and prettier to look at.
Modernization and translation aren't the same thing
Suppose you have a mature desktop application that's been in use for twenty years.
It contains hundreds of procedures, windows, reports, menus, fields, buttons, and workflows.
Someone decides the product needs to be modernized.
The first question often becomes:
How do we get all of this into a browser?
That's a perfectly reasonable technical question.
It may be a terrible product question.
The browser isn't the goal.
Neither is React, mobile, cloud hosting, or whatever other technology happens to be involved.
The goal is to solve somebody's problem better than we're solving it now.
That means the first question should probably be something more like:
What do people actually need to do in this new environment?
Those two questions can lead to completely different products.
One begins with the existing software and tries to preserve it.
The other begins with the user and tries to understand the work.
That's the difference between modernization and translation.
Existing software is evidence, not necessarily specification
A mature application contains an enormous amount of valuable knowledge.
That's especially true for business software that's been used for years.
The application may know:
- How prices are calculated
- Which fields are required
- Which business rules matter
- Which unusual cases occur in the real world
- Which data has to survive
- Which regulations apply
- Which operations depend on one another
- Which mistakes customers actually make
- Which exceptions somebody learned about the hard way fifteen years ago
You don't want to throw that away.
But that doesn't mean every screen, menu, workflow, and report deserves the same respect.
A screen may exist because a 1998 database library worked a certain way.
A twelve-step workflow may exist because three departments once passed paper between them.
A report may exist because the only practical way to review information was to print everything and look through it.
A menu structure may exist because the original application had to fit into the conventions of a desktop environment that no longer matters.
Those things are part of the application's history.
They aren't automatically part of the product's future.
That's why I think a useful rule for legacy modernization is:
Preserve the knowledge. Question the implementation.
The business rules may be priceless.
The seventeen-tab dialog box probably isn't.
A phone isn't a tiny desktop computer
This becomes especially obvious when people talk about mobile versions of existing business applications.
It's technically possible to take a large desktop application and make all of its screens available on a phone.
That doesn't mean anyone wants to use it that way.
Imagine a well-designed automotive repair application.
At the front desk, the staff may need access to:
- Customer history
- Vehicle history
- Estimates
- Parts
- Labor
- Scheduling
- Invoices
- Payments
- Warranty information
- Inventory
- Reports
- Accounting information
There's nothing wrong with that.
The desktop application may be exactly where all of those capabilities belong.
Now suppose the shop wants a mobile component.
The mechanic or service adviser is standing beside a car in the service bay with a tablet.
What does that person need?
Maybe the job is simply:
- Find or add the customer
- Find or add the vehicle
- Record the mileage
- Record what the customer says is wrong
- Take a few photographs
- Start the inspection or service request
That's a useful mobile application.
It may use the same database.
It may use the same customer records.
It may obey the same business rules.
But it doesn't need to reproduce the entire desktop product on a six-inch screen.
The right question isn't:
How do we make the automotive application mobile?
It's:
What work should someone be able to do while they're standing beside the vehicle?
That's a much better question.
Different environments create different opportunities
The same thing applies to web applications.
There are things a desktop application does extremely well.
There are things a browser does better.
There are things that make sense on a tablet.
There are things that make sense on a phone.
Those environments aren't merely different screen sizes.
They change where the user is, what the user is doing, what information is available, and what capabilities the device can contribute.
A phone has a camera.
It knows where it is.
It can scan a QR code.
It can make a call.
It can send a message.
It travels with the user.
A tablet can be carried around a warehouse, examination room, job site, restaurant, sales floor, or repair bay.
A browser can give a customer access to information without installing anything.
Those are new capabilities.
If all we do is reproduce the old application's menus and forms, we're ignoring most of what made the new environment interesting in the first place.
We've spent a lot of effort moving the cow path onto a newer piece of property.
Sometimes the best new screen replaces twenty old ones
Modernization should give us permission to ask why things exist.
Suppose the old application has a six-step process for entering information.
Why?
Maybe each step corresponds to an old departmental boundary that no longer exists.
Maybe the data had to be entered twice because two systems couldn't communicate.
Maybe somebody had to run a report, print it, sign it, and give it to someone else.
Maybe an operator had to select information the new system can determine automatically.
If we faithfully reproduce all six steps, we've preserved history.
We haven't necessarily preserved value.
A genuinely modern system might eliminate four of the steps.
That can be uncomfortable when you're working from an existing application because the existing program feels authoritative.
It's real.
It works.
People know how to use it.
It contains years of accumulated behavior.
But sometimes the most valuable thing you can ask about an existing procedure is:
Why are we doing this at all?
If nobody can give you a good answer, don't start writing the React component yet.
AI can pave cow paths unbelievably fast
AI makes this problem more important.
Years ago, reproducing a large application on another platform was expensive enough that somebody usually had to think hard before doing it.
Hundreds of screens represented a lot of work.
Today we can give an AI agent a repository and say:
Convert this application to a modern web stack.
And it may be able to do an astonishing amount of that work.
It can inspect the old forms.
It can trace the data.
It can reproduce the business logic.
It can build APIs.
It can create React components.
It can make the pages responsive.
It can add tests.
It can document the whole thing.
That's an incredible capability.
It's also an incredibly efficient way to preserve assumptions nobody has questioned.
The result may look thoroughly modern.
It may use current libraries.
It may run in the cloud.
It may resize beautifully on a phone.
And underneath all of that modern technology may be a workflow designed around the limitations of a dot-matrix printer.
AI didn't make that mistake.
We did.
We gave it the wrong assignment.
Reproduction is exactly what AI is good at
There's an important irony here.
One of AI's great strengths is its ability to understand an existing system and produce something analogous in another technology.
That's useful.
Sometimes that's exactly what we need.
If an existing business rule is correct, we want it preserved.
If a calculation has been proven for twenty years, rewriting it creatively isn't a virtue.
If customers depend on a particular behavior, compatibility matters.
But the better AI gets at reproducing software, the more important it becomes to separate two questions:
What do we need to preserve?
and:
What do we need to rethink?
If we don't make that distinction, the AI won't necessarily make it for us.
Why would it?
We showed it an application and asked it to rebuild the application.
So it did.
Don't confuse familiarity with requirement
Legacy applications accumulate habits.
Users know where things are.
Developers know how the pieces fit together.
Companies have procedures written around them.
All of that creates a powerful temptation to assume that the existing workflow is the requirement.
Sometimes it is.
Sometimes a particular sequence exists because the business genuinely requires it.
But sometimes people are doing something because that's how the software made them do it twenty years ago.
After enough time, nobody remembers which is which.
That's why modernization needs discovery before implementation.
Ask people what they're trying to accomplish.
Watch what they actually do.
Find out which screens they use constantly.
Find out which ones they barely touch.
Find out which information they're writing on a piece of paper because the software doesn't give it to them where they need it.
Find out which reports nobody reads.
Find out which steps exist only to compensate for another limitation in the application.
Don't just ask:
What does this screen do?
Ask:
Why does anybody need this screen?
Those are very different questions.
Start with the work, not the windows
Before converting an existing application to another platform, I think there are several questions worth asking.
What job is the user actually trying to do?
Describe the job without mentioning the existing screen.
If the answer begins with "they open the Customer window and click...", you're probably describing the software rather than the work.
Where will they be doing it?
At a desk?
Beside a vehicle?
Walking through a warehouse?
Standing in front of a customer?
Sitting at home?
The environment matters.
What information do they need right then?
Not everything the system knows.
What does this person need for this job at this moment?
What can the new environment do that the old one couldn't?
Camera?
Location?
Touch?
Instant communication?
Remote access?
Automatic synchronization?
A public link?
Use the new platform for what makes it useful.
Which old steps can disappear?
This may be the most valuable question of all.
Modernization isn't only about gaining capability.
Sometimes it's about removing work.
This isn't an argument for rewriting everything
Questioning the old application doesn't mean throwing it away.
In fact, I think "rewrite it all" can be another form of bad thinking.
A mature product may contain decades of proven code and business knowledge.
Keep what's valuable.
Keep the rules that are right.
Keep the calculations that work.
Keep the data model where it still makes sense.
Keep the strange little exception that exists because somebody eventually discovered that one customer in Nebraska really does need it.
But don't preserve a bad workflow merely because the business logic inside it is valuable.
Separate them.
The knowledge deserves respect.
The presentation deserves review.
A modern-looking cow path is still a cow path
It's easy to be impressed by visible modernization.
The application now runs in a browser.
It has a responsive layout.
The buttons are rounded.
There's a hamburger menu.
It works on an iPhone.
There's an API behind it.
The whole thing is running in containers on somebody's cloud.
Great.
Now ask the question that actually matters:
Is the user doing the right work in the right way?
If the answer is no, the technology doesn't rescue us.
We've paved the cow path.
Maybe we've even added streetlights.
The better question comes first
This is one of the reasons I keep coming back to the name of this site.
Good software development begins with good questions.
Especially when we're modernizing something old.
Don't begin with:
How do we put this program on the web?
Try:
What should this person be able to accomplish through the web?
Don't begin with:
How do we make all these screens work on a phone?
Try:
What part of this work actually belongs on a phone?
Don't begin with:
Can AI convert this entire application?
It probably can do more of it than you think.
Ask:
Which parts should survive the conversion?
Technology has changed enormously in the forty-plus years I've been using the expression "paving cow paths."
The question underneath it hasn't changed at all.
Before you make the old road faster, smoother, prettier, or easier to travel, make sure it's still the road you want.
Related Field Note
For the hotel management story that taught me this lesson more than forty years ago, see The 20 Rooms That Matter.