Legacy System Modernization Case Study How We Cut Manual Hours and Lifted Conversions
The warning sign was not a system crash. It was a spreadsheet.
Every morning, three people opened the same legacy order system, exported yesterday’s requests, checked them against stock records, copied customer details into a quote template, and emailed the result back to the customer. The work was familiar, but fragile. One missed field could delay a quote by a day. One unavailable staff member could create a backlog.
This case study breaks down how a mid-sized legacy business moved from a closed internal system to a customer web portal without replacing everything at once.
The company in this anonymised workflow teardown was a UK-based B2B supplier with repeat customers, complex pricing, and a legacy back-office system that still handled stock, credit status, and fulfilment well. The problem was not that the legacy system was useless. The problem was that too much valuable work sat outside it.
Over 16 weeks, the team moved the highest-friction customer tasks into a secure web portal. The result was a measurable drop in manual admin and a clear lift in quote-to-order conversion.
The starting point was a business process held together by people
The legacy system had been running for more than a decade. It stored products, customer accounts, contract prices, stock levels, delivery addresses, invoices, and order history.
For internal staff, it was reliable enough. For customers, it was invisible.
That created a familiar pattern:
Customers emailed quote requests as PDFs, spreadsheets, or plain text.
Sales staff copied details into the legacy system to check pricing and stock.
Operations confirmed availability by email or internal message.
Sales created a quote document manually.
Customers replied with changes, questions, or purchase orders.
Staff re-entered the same information to create the final order.
The same data moved through too many hands.
Before the migration, a typical quote required 24 minutes of manual handling. The business processed about 1,150 quote requests per month, which meant roughly 460 manual hours per month went into quote intake, checking, formatting, and follow-up.
The conversion rate from quote request to confirmed order was 18.4%. That was not terrible, but the sales team suspected that slow replies were costing them repeat work. When quotes arrived after the customer had already sourced the item elsewhere, the outcome was predictable.
The team set three targets before touching the technology:
Metric | Before migration | Target |
Average manual handling per quote | 24 minutes | Under 10 minutes |
Monthly admin hours on quote processing | 460 hours | Under 220 hours |
Quote-to-order conversion rate | 18.4% | At least 23% |
Average first response time | 1.8 working days | Same day for standard requests |
Duplicate data entry points | 5 | 2 or fewer |
The brief was not “replace the legacy system”. That would have been expensive, slow, and risky.
The brief was sharper: move customer-facing work into a portal while keeping the legacy system as the system of record.
That decision shaped the whole project.
Step by step, the team moved the workflow into a portal
The migration worked because the team avoided a big-bang rebuild. They broke the work into clear stages, each tied to a business result.
This is the same approach many companies look for when researching legacy system modernisation for a customer portal, especially when the old system still contains important operational logic.
Step 1. Map the real workflow, not the official one
The first week was spent watching the work happen.
The project team sat with sales, operations, finance, and customer service. They tracked 40 quote requests from first email to final order. The goal was to understand where time disappeared.
The official process looked simple:
Receive request.
Check stock and price.
Send quote.
Confirm order.
The real process had more detail:
Some customers used old product codes.
Some accounts had contract-only pricing.
Some products had minimum order quantities.
Some buyers needed approval documents.
Some delivery postcodes required special carriage rules.
Some orders could not proceed if an account was on credit hold.
These rules lived partly in the legacy system, partly in staff knowledge, and partly in old email threads.
The portal could not succeed by copying a paper form onto a screen. It had to reflect the messy truth of the workflow.
The team created a process map with three labels for each step:
Keep
The legacy system already handled this well.
Expose
Customers needed access to this data or action.
Automate
A rule could remove manual checking or retyping.
That simple classification stopped the project from drifting into unnecessary rebuilds.
Step 2. Choose the first portal features by workload
The team did not begin with the most impressive features. They began with the most repeated tasks.
The first portal release included:
Customer login with account-specific pricing.
Product search using current and legacy item codes.
Live stock status grouped into simple bands, such as available, low stock, or back order.
Quote basket for repeat and bulk requests.
Saved delivery addresses.
PDF quote generation.
Request status tracking.
Internal review queue for exceptions.
The choice of stock bands mattered. The legacy system held exact stock values, but exposing exact numbers to customers created commercial and operational concerns. A banded status gave customers useful information without creating new risk.
The team also resisted adding online payment in the first release. Most customers used account terms, purchase orders, or internal approval flows. Payment would not remove the largest bottleneck, so it waited.
Step 3. Build an integration layer instead of forcing direct access
The hardest technical question was how the web portal should talk to the legacy system.
Direct database access looked tempting. It was fast to set up and gave the portal access to everything. It was also risky. The legacy database had old naming conventions, undocumented field meanings, and business rules hidden in stored procedures.
The team chose an integration layer instead.
The portal did not query the legacy database directly. It called a set of APIs that handled:
Customer account lookup.
Product search.
Price calculation.
Stock availability.
Quote creation.
Order hand-off.
Status updates.
This added effort at the start, but it paid off quickly.
The integration layer protected the legacy system from heavy traffic. It also gave the team a place to translate old data structures into cleaner portal responses. For example, the legacy system used several product status codes that only internal users understood. The API converted those into plain labels customers could act on.
This also made error handling much clearer. If a price rule failed, the portal did not show a broken page. It routed the request to the internal review queue with the reason attached.
Step 4. Clean only the data customers would touch
Data quality was a real obstacle.
The legacy system contained duplicate product names, inactive stock lines, old customer contacts, and delivery addresses entered in different formats. Cleaning everything would have taken months.
The team took a narrower route. They cleaned the data needed for the portal launch:
Active products sold in the last 18 months.
Top 320 customer accounts by quote volume.
Current contract price records.
Delivery addresses used in the last year.
Common legacy product codes still used by customers.
This avoided a common migration trap. Data migration does not need to be perfect everywhere on day one. It needs to be reliable where users will depend on it.
The team also added validation rules at portal entry points. Customers could not submit a quote request with missing delivery details, invalid quantities, or unsupported file types. That reduced clean-up work before requests reached staff.
Step 5. Pilot with customers who would tell the truth
The pilot group included 28 customers. They were not chosen because they were easy. They were chosen because they represented the real mix of order behaviour:
Frequent repeat buyers.
Customers with contract pricing.
Buyers who used old product codes.
Accounts with several delivery locations.
Customers who often asked for revisions.
The pilot ran for four weeks.
During that time, the team measured completion rates, support requests, failed searches, quote revisions, and time to first response. They also reviewed portal session recordings where consent and privacy controls allowed it, looking for friction in the journey.
Three problems appeared quickly.
The first was search. Customers typed model numbers, old codes, partial descriptions, and supplier references. Exact-match search failed too often. The fix was a synonym table and fuzzy matching for common patterns.
The second was trust. Some buyers still emailed after using the portal because they wanted confirmation that the request had arrived. The fix was better status messaging, automatic confirmation emails, and a clear quote reference number.
The third was exceptions. Not every quote could be automated. The fix was not to hide those cases. The portal flagged them clearly and showed “under review” rather than pretending the answer was instant.
Step 6. Roll out with staff training built around exceptions
The internal launch focused less on how to use the portal and more on how the work would change.
Staff no longer had to copy every request into the system. Their role shifted towards handling exceptions, supporting customers, and improving data.
The team created short playbooks for common scenarios:
What to do when a product code does not match.
How to handle a blocked account.
How to correct an address without creating duplicates.
How to review a price exception.
When to contact the customer rather than send a system message.
This helped staff trust the portal. It also stopped workarounds from creeping back in.
The main challenges were operational, not just technical
The migration looked like a software project from the outside. Inside the business, it was a workflow change.
Several challenges mattered more than code.
The legacy system contained hidden business logic
Some pricing rules were not documented. Staff knew them because they had dealt with edge cases for years.
The team solved this by logging every manual override during the discovery and pilot stages. Each override became one of three things:
A rule to build into the integration layer.
An exception to route to staff.
A policy decision for the business to simplify.
This reduced the risk of automating the wrong behaviour.
Customer data was inconsistent
Customer accounts had old contacts, retired addresses, and duplicated buyer names. Rather than block the portal launch, the team added a “confirm your details” step on first login.
Customers could suggest corrections, but staff approved changes before they reached the legacy system. That protected data quality while spreading the clean-up workload naturally.
Staff worried automation would remove control
The sales team knew that relationships mattered. They did not want good customers pushed through a cold system.
The solution was to keep human touchpoints where they added value. High-value quotes, unusual requests, and strategic accounts still received personal follow-up. The portal removed copying and chasing, not judgement.
Reports had to compare old and new workflows
At first, managers struggled to compare email requests with portal requests. The answer was a shared reporting model.
Every request, whether submitted by email during transition or through the portal, received the same status categories:
Received.
Awaiting review.
Quoted.
Revised.
Ordered.
Lost.
Cancelled.
This made before-and-after measurement credible.
The results after 90 days showed where the value came from
After full rollout, the team measured the first 90 days against the three-month baseline before migration.
The biggest gain was manual time saved.
Average handling time per quote dropped from 24 minutes to 9 minutes. Monthly quote volume stayed broadly similar, moving from 1,150 to 1,210 requests. Even with slightly higher volume, admin effort fell from about 460 hours per month to 182 hours per month.
That saved 278 manual hours per month, equal to more than 8 full working weeks of admin time.
The quote-to-order conversion rate rose from 18.4% to 25.7%. The team attributed the lift to faster responses, clearer stock visibility, easier repeat ordering, and fewer abandoned requests.
Metric | Before | After 90 days | Change |
Average manual handling per quote | 24 minutes | 9 minutes | 62.5% lower |
Monthly admin hours | 460 hours | 182 hours | 278 hours saved |
Quote-to-order conversion | 18.4% | 25.7% | 7.3 percentage points higher |
Average first response time | 1.8 working days | 3.6 hours | Much faster |
Requests needing rework | 31% | 12% | 19 percentage points lower |
Customer status-chasing emails | 410 per month | 145 per month | 265 fewer emails |
The portal did not create value by looking modern. It created value by removing repeated handoffs from the quoting process.
The conversion gain was especially visible for repeat customers. Buyers who used saved baskets and existing delivery addresses completed requests faster and returned more often.
The internal benefit was just as important. Staff spent less time formatting quotes and more time resolving useful problems, such as missing product data, unusual pricing, and stock alternatives.
The lessons apply to most legacy system modernisation projects
A web portal can improve a legacy business without tearing out the core system straight away. The key is to modernise the workflow around the system, then replace deeper parts only when the business case is clear.
Four lessons stood out.
Start with the work, not the software. The process map revealed where time was really being lost. Without that, the team could have built a polished portal that failed to remove admin.
Keep the legacy system where it still performs well. Stock, credit status, and order history stayed in the original system. The portal made those functions easier to access.
Treat exceptions as part of the design. A good portal does not need to automate every case. It needs to route unclear cases cleanly, with enough context for staff to act.
Measure from the start. The team knew the baseline before launch, so the results were credible. Manual hours saved and increased conversion rates were not vague claims. They were tied to agreed metrics.
For businesses searching for ways to migrate legacy business systems to a web portal, the safest path is rarely a full rebuild on day one. A focused portal can remove the worst friction first, protect existing operations, and create the evidence needed for the next stage of change.
The practical takeaway is simple: choose one high-volume workflow, measure it honestly, expose the right parts of the legacy system, and build around the exceptions. That is how modernisation becomes less risky, and much more useful.
Comments