Day 1: understanding what the system actually does
Most modernization projects start with a technology decision. What framework are we moving to? What cloud provider? What database?
This one started with a single question: what does the system actually do?
The answer was complicated. The security model alone was a product of 15 years of real-world use. Permissions were role-based, but the roles had been modified so many times that the original design was unrecognizable. Some users had access to screens they should not have. Some screens were locked behind permissions that nobody remembered creating. The whole thing worked in production but nobody could explain why.
Day one was spent mapping the security model against actual user behavior. Not what the database said. Not what the code said. What the users actually did. Which screens did each role access? Which data did they modify? Which reports did they run?
This step took a full day. A less experienced team would have skipped it and started rewriting immediately. That is how modernization projects run six months over schedule. The security model is always where the complexity hides.
Day 2: replicating the security model, not the code
Once the actual security behavior was mapped, the next step was not to port the old authentication code. It was to rebuild the security model from scratch using modern patterns, configured to produce the same outcomes.
This is the difference between migrating and modernizing. Migration copies the old system into a new environment. Modernization rebuilds the system to do what the old system actually did, minus the accumulated cruft.
The new security layer used ASP.NET Core Identity with custom policy-based authorization. Every permission from the old system was mapped to a policy. Every role inherited the correct policies. The result was a security model that produced identical access patterns to the old system but was centralized, testable, and documented.
The key insight: nobody on the client's team could have specified this from memory. The security model was too complex and too evolved. But by starting from actual behavior instead of code, the rebuild took a day instead of a week.
Day 3: standing up the infrastructure
The old application had no CI/CD pipeline. No automated builds. No deployment process beyond copying files to a server. No environment parity between development and production.
Day three was infrastructure day. A Bitbucket pipeline was configured to build the application on every commit. Branch-based deployments were set up so that staging and production environments could be managed independently. The deployment process went from manual file copies to a single command.
This sounds like infrastructure work, but it was really a business decision. The client's team had been afraid to touch the application for years because any change could break something in production and there was no way to roll back. By the end of day three, they had a pipeline where changes could be tested in staging, promoted to production, and rolled back if something went wrong.
That is not a technology upgrade. That is a risk reduction. It changes how a team feels about their own software.
Day 4: verifying it all works
Day four was verification. The application was running internally on the new infrastructure. The security model was producing identical access patterns. The CI/CD pipeline was building and deploying. A small group of internal users tested the application against their real workflows.
Bugs were found. Edge cases surfaced. That is expected. The difference is that with a CI/CD pipeline and automated deployments, fixes could be pushed in minutes instead of days.
By the end of Thursday, the application was running internally. The security model was modernized. The deployment process was automated. The month-long scope was functionally complete.
Why this worked
This project succeeded for three reasons that have nothing to do with technology.
First, the developer understood both worlds. The legacy stack (Windows, IIS, SQL Server, custom auth) and the modern stack (.NET 8, Bitbucket Pipelines, branch-based deployments). A developer who only knows modern tooling would have spent the first week learning why the old system was built the way it was. A developer who only knows legacy tooling would have ported the mess instead of fixing it. Knowing both meant the modernization was based on understanding, not translation.
Second, the approach started with behavior, not code. The security model was rebuilt from how users actually used the system, not from how the code was written. This is faster, more accurate, and produces a cleaner result. But it requires the judgment to know which part of the old system matters (the outcomes) and which part does not (the implementation).
Third, AI acceleration was real but not the headline. AI tools helped with boilerplate, test generation, and pipeline configuration. They saved hours on documentation and repetitive configuration. But the decisions about what to build, in what order, and how to verify it, those were all human. AI made a fast developer faster. It did not replace the need for a fast developer.
What this means if your business runs on old software
A lot of manufacturing companies are in the same position. The software that runs the business was built years ago, by people who are no longer there, in stacks that are no longer current. It works in production but nobody wants to touch it. The team knows it needs modernization but assumes it will take months and cost a fortune.
It does not have to.
The difference between a six-month modernization and a four-day modernization is not the technology. It is the approach. Start from behavior, not code. Understand what the system actually does before deciding what to rebuild. Know both the old world and the new world well enough to bridge them without carrying the baggage.
And most importantly, hire someone who has done this before. Not someone who has read about it. Someone who has walked into a factory, looked at a system frozen in 1998, and known what to keep and what to throw away.
That is the difference between migrating and modernizing. And it is the difference between a month and four days.
Book a discovery session if your business runs on software that works but nobody wants to touch.