Every Singapore manufacturer running a system older than eight years is sitting on a migration decision. The system works — barely. The vendor support contract costs more each year. The customisations from 2018 break every time someone applies a patch. The person who configured it has left the company.
The migration question is not whether to move. It is how to move without losing data, breaking operations, or spending twelve months on a project that should take twelve weeks.
Replace vs Wrap
The first decision is whether to replace the legacy system entirely or wrap it — keep the parts that work and build the missing operational layer around it.
Replace when: - The vendor has ended support or the product is end-of-life. - The data model is fundamentally wrong for your current operations (you have changed since the system was implemented). - The cost of annual maintenance + workaround management exceeds the cost of a new system over 3 years. - Nobody on staff understands the customisations. - The system cannot integrate with modern tools (no API, no export capability).
Wrap when: - The legacy system handles finance well (GL, GST, bank reconciliation) and the accountant knows it. - The operational gaps are specific — quoting, production tracking, supplier coordination, quality — not the entire system. - The data in the legacy system is clean enough to integrate with (even if the system itself is limited). - You want to reduce migration risk by changing fewer things at once.
The wrap approach is what Start Canyon recommends for most Singapore SMB manufacturers. The legacy accounting system stays. The new operational system handles quoting, production, supplier coordination, and quality. The two integrate via API or file export. Total cost: S$10,000-S$30,000 for the new layer, zero migration cost for the accounting system.
The Data Migration Problem
Legacy ERP data is never clean. After 5-10 years of use, every system accumulates:
Duplicate records. The same customer entered three times with slightly different names. The same supplier with two different codes. The same product with a legacy code and a current code.
Orphaned transactions. Purchase orders that were never closed. Sales orders from 2019 still showing as open. Production orders that completed but were never confirmed in the system.
Unstructured data. Critical information stored in free-text notes fields because the system did not have the right structured field. Customer pricing terms in a notes field. Supplier lead times in a comment. Quality requirements described in prose.
Inconsistent data. Units of measure that changed over time but were not retroactively updated. Product categories that do not match current operations. Cost centres that reflect an organisational structure from three years ago.
The migration effort is dominated by data cleaning, not data moving. Moving clean data from one system to another is straightforward. Identifying what is wrong, deciding what to fix vs what to discard, and validating the result — that is the real work.
The Phased Migration Strategy
The lowest-risk migration approach for Singapore manufacturers is phased:
Phase 1: Build the new operational layer (weeks 1-10). Build the new system in parallel while the old system continues to run. No disruption to daily operations. The new system is built against the target workflow, not as a replica of the old system.
Phase 2: Migrate master data (weeks 8-10, overlapping with Phase 1). Customer records, supplier records, product catalogue, BOMs. These are the foundation records that the new system needs. Clean them during migration — this is the opportunity to fix the duplicates and inconsistencies.
Phase 3: Parallel run (weeks 11-14). Run both systems simultaneously for 2-4 weeks. New transactions go into both systems. Compare outputs daily. This proves that the new system produces correct results before the old system is decommissioned.
Phase 4: Cutover (week 14-15). Stop entering new transactions into the old system. The new system becomes the primary. The old system is kept read-only for reference for 3-6 months, then archived.
Phase 5: Open transactions migration (week 15-16). Migrate open sales orders, open purchase orders, and current inventory balances from the old system. This is done last because these records change daily — migrating them too early means they are immediately stale.
What Not to Migrate
Not everything in the legacy system needs to move:
- Closed transactions older than 2 years. Keep them in the old system (read-only archive) or export to CSV for reference. Do not clutter the new system with historical data that nobody queries.
- Superseded product codes. If a product was renamed or recoded, only migrate the current code. Map old codes to new codes in a reference table for customer support.
- Workaround data. If the old system has fields or records that exist only to support a workaround for a limitation, do not migrate the workaround. The new system should handle the requirement natively.
- Test data. Training records, test transactions, and demo data from the original implementation. Delete before migration.
The Parallel Run
The parallel run is the safety net. For 2-4 weeks, every transaction goes into both the old and new systems. At the end of each day, a comparison check verifies that both systems produce the same outputs — same inventory balances, same job costs, same invoice totals.
The parallel run is operationally expensive (double entry) but it does two things no amount of testing can do:
1. It proves the new system works with real transactions, real edge cases, and real user behaviour. 2. It gives the team confidence that the new system is correct before the old system is switched off.
Manufacturers who skip the parallel run (hard cutover) take on significantly more risk. If the new system produces an incorrect result on day one and there is no fallback, the operational impact is immediate.
Start Canyon includes a parallel run plan in every migration engagement. The run is typically 2 weeks for simple operations and 4 weeks for manufacturers with complex pricing, multi-supplier coordination, or regulatory documentation requirements.