Case Study: Migrating 13,602 SKUs and Flagging 7,295 Inactive Candidates
ERP data migration case study — 13,602 Sage SKUs analysed, 7,295 inactive candidates flagged, and removed or set inactive on web after client sign-off.
July 2026 · 10 min read
Data quality is a software delivery lever. When obsolete records dominate production systems, users lose trust and engineering teams waste cycles maintaining records that should not be live.
Project context and challenge
The engagement is documented in the published case study. The source database had expanded over years without consistent governance, leaving inactive records visible and high-value data underrepresented in the customer-facing application.
| Metric | Baseline |
|---|---|
| Sage SKUs analysed | 13,602 |
| Inactive candidates flagged | 7,295 |
| Live web products with structured metadata | 2,291+ |
| Primary issue | Low signal-to-noise in production data layer |
Approach: cleanup without operational disruption
- Pulled and normalised records into an auditable staging environment.
- Defined status logic for active, obsolete, and review-required entries.
- Cross-checked usage activity and business indicators to avoid removing viable data.
- Ran stakeholder review rounds before each major archive batch.
- Published cleaned structure and monitored application behaviour post-release.
Quality controls used during removal
Risk control checklist
No record removed without status evidence and client review sign-off.
Category-level spot checks before and after each publish cycle.
Redirect and replacement handling for high-traffic legacy references.
Change logs retained for rollback and accountability.
Business team validation on top-value records before go-live.
Outcomes and business impact
| Area | Impact |
|---|---|
| User navigation | Cleaner journeys with fewer irrelevant screens. |
| Internal maintenance | Reduced admin burden on teams curating obsolete data. |
| Integration reliability | Higher data density for sync and reporting pipelines. |
| Commercial clarity | Stronger prioritisation of records with live demand. |
What other software projects can copy
- Treat data cleanup as a software delivery workstream, not a one-off tidy-up.
- Set objective record lifecycle rules before platform decisions.
- Archive in controlled waves with sign-off, not one risky bulk action.
- Connect cleanup to integration, reporting, and UX goals.
- Maintain governance after launch so obsolete data does not return.
Related guide
For the process framework behind this project, read how to clean legacy data before launching software.
Frequently asked questions
- Why remove obsolete records instead of keeping everything in production?
- Large volumes of inactive data reduce application quality, confuse users, and dilute performance for records that actually matter.
- How do you avoid deleting data that still matters?
- Use status rules, usage history checks, and staged client approval before each removal wave so viable records are protected.
- Is data cleanup only useful before a new platform build?
- No. It improves integration reliability, user confidence, and team efficiency even on existing systems.
- How long does a large-scale data migration usually take?
- Timeline depends on record volume and data quality, but structured phases with staged releases often deliver usable gains within weeks.
- What KPI should be tracked after migration?
- Track data completeness, user engagement quality, integration error rates, and operational effort spent on data maintenance.