The client called us on a Tuesday afternoon. Their order management system had crashed for the third time that week. Each outage lasted between two and four hours, and every hour of downtime cost them roughly €12,500 in lost orders and idle staff. They'd had this system for 15 years. The original development company had dissolved. The one developer who still understood the codebase had retired 18 months earlier. They needed a path forward, and they needed it fast.
We told them 90 days to a full replacement. They thought we were either very confident or completely wrong. Here's an honest account of how that project actually went.
What We Found During the Assessment Week
Before committing to any timeline, we spent a week embedded with their team — sitting with warehouse staff during their morning shift, watching the sales team navigate the interface, and pulling the actual database schema and server logs.
The technical picture was worse than the initial brief suggested:
- A Windows Server 2008 machine running an ASP.NET WebForms application with no source control history
- A SQL Server 2008 database with 847 stored procedures, many undocumented
- Average page load time of 5–8 minutes for the main order entry screen
- No mobile access — the entire system required Internet Explorer 11 on-site
- 8+ hours of unplanned downtime per month over the previous quarter
- Annual maintenance contract at €185K/year with a vendor doing little more than keeping the server alive
The human picture was equally important. The warehouse team had developed workarounds: paper backup sheets, a personal spreadsheet one supervisor kept on his phone, a WhatsApp group where order changes got announced. The system wasn't just slow — it had stopped being trusted.
The Architecture Decision
There were two realistic paths: incremental modernization of the existing codebase, or a clean rebuild on a modern stack with parallel operation until cutover. We recommended the rebuild, and our reasoning was straightforward.
The existing codebase had no tests, no documentation, and no one who fully understood the stored procedure dependencies. Modifying it incrementally would mean working blind. The risk of breaking something critical while trying to improve it was high. A parallel rebuild let us define the scope clearly, test against real usage, and cut over on a date we controlled.
The stack we chose:
- Frontend: Vue.js 3 with TypeScript — fast to develop, easy for their team to maintain, excellent mobile support out of the box
- Backend: .NET Core 8 Web API — the team had .NET experience, and the performance improvement from WebForms to Core was dramatic
- Database: SQL Server on Azure SQL — minimal data migration complexity, familiar schema, managed backups and failover
- Infrastructure: Azure App Service with autoscaling — no more single point of failure on one aging server
- Team: 4 developers, 1 DevOps engineer, 1 project manager, 1 QA automation engineer
The 90-Day Execution
Weeks 1–2: Discovery and Architecture
We mapped every workflow the old system supported by watching users rather than reading specs. There were no up-to-date specs. The warehouse supervisor's paper backup sheets turned out to be the most accurate documentation of how orders actually flowed through the business. We used those as our requirements baseline and supplemented with two formal workshops with department heads.
Weeks 3–6: Core Build
The first four weeks covered the highest-priority workflows: order entry, inventory lookup, and the daily picking and dispatch process. We ran weekly demos with the warehouse team, which caught several workflow assumptions we'd gotten wrong. The original system had a quirk where orders from one specific customer segment had a different priority handling — something that wasn't in any documentation but was deeply embedded in the team's daily habits. We would have missed it without the weekly demos.
Weeks 7–9: Data Migration and Integration
The data migration was the part we were most cautious about. Fifteen years of order history, customer records, and product catalog data — some of it in inconsistent formats, some of it referencing records that no longer existed. We built the migration scripts in week seven and ran them against a staging copy of the production data three times before trusting the results. We also kept the old system running during this phase so staff could cross-reference records if anything looked off.
The integration with their accounting software (Sage) was the most time-consuming single piece of the project — largely because the Sage API documentation was incomplete and we had to test against a live instance to understand its actual behavior. We built in a week's buffer for this, which turned out to be exactly what we needed.
What nearly derailed us
In week eight, we discovered that the old system had been calculating shipping costs using a fee schedule that hadn't been updated since 2019. The new system used current rates. This wasn't a bug — it was a decision point. We flagged it immediately, got a client decision within 24 hours, and updated the configuration. Finding this before launch rather than after saved what could have been a confusing month of invoice discrepancies.
Weeks 10–12: Parallel Operation and Cutover
For two weeks, both systems ran simultaneously. New orders were entered in both systems. This sounds inefficient and it is — but for a manufacturing business where an order processing error can mean a missed delivery commitment, it was the right call. It gave the team confidence in the new system before the old one was turned off, and it gave us a comparison baseline to catch any calculation differences.
We cut over on a Friday afternoon at 3pm — deliberately timed to be after the week's last dispatch run and before the following Monday's order intake. The transition itself took 45 minutes. The old server stayed on standby for two weeks post-cutover and was never needed.
The Numbers After 90 Days
We measured against the baseline we'd established in the assessment week:
- Order entry page load time: from 5–8 minutes to under 2 seconds
- System uptime: from ~95% to 99.9% (one 23-minute planned maintenance window in the first 90 days post-launch)
- Mobile accessibility: 0% to 100% — any device, any browser
- Support tickets to the IT team related to the system: down 62% in the first month
- Annual infrastructure and maintenance cost: from €185K/year to €38K/year
The warehouse supervisor retired his paper backup sheets in week three of the new system. That felt like a more honest success metric than any of the numbers above.
What Made the 90-Day Timeline Possible
This kind of legacy system modernization doesn't always go well. We've seen similar projects take 18 months or get cancelled. A few things made the difference here:
A fixed scope with clear cut lines. We agreed upfront that version 1 would match the functionality of the old system, not exceed it. Feature requests during the project went into a post-launch backlog, not into the current sprint. This discipline is harder to maintain than it sounds — clients naturally want to improve things while you're rebuilding them, and the impulse is reasonable. But scope creep is what turns 90-day projects into 9-month ones.
Real users in the process weekly. Software built without regular user input during development tends to be technically correct but practically wrong. The people who use a system every day know things about it that aren't written anywhere. Weekly demos with the actual warehouse and sales staff caught problems early enough to fix without significant rework.
A DevOps foundation from day one. We set up CI/CD pipelines, automated testing, and infrastructure-as-code before writing the first line of application code. This meant deployments were automated and reliable throughout the project, which removed a category of risk that kills momentum in many legacy modernization efforts.
Choosing boring technology. Vue.js and .NET Core aren't the newest things available. They're mature, well-documented, and have large support communities. When we hit problems — and we did — finding solutions was fast. Choosing stable, proven technology over whatever's newest is often the right call for a time-constrained project.
What Happened After 90 Days
Six months post-launch, the client ran their first post-implementation review. The quantified savings — infrastructure costs, reduced maintenance contract, productivity gains from faster order processing — totaled €247K in the first year. The system rebuild had cost €148K. They've since added two new modules (a customer portal and a reporting dashboard) that wouldn't have been possible at all on the old architecture.
More importantly, the operations team trusts their system again. That's harder to put in a spreadsheet, but it changes how a company operates.
If your business is running on software that's regularly crashing, painfully slow, or simply can't support the way you need to work today, the question isn't usually whether to modernize — it's when and how. A properly scoped legacy system replacement with the right technology choices and a disciplined approach to scope is achievable in 90 days. Not always. But more often than most companies assume.
If you're evaluating partners for a project like this, our nearshore software development team operates from Tunisia — French and Arabic speaking, European timezone, 60% lower cost than Western Europe. Let's talk about your project →
