"The original vendor says this system is no longer maintained, but 400 orders a day still run through it." That is the call we take most often this year. The caller usually has a system commissioned 8 to 12 years ago, running on an environment that lost support long ago, with the original developer unreachable and 600,000 transactions sitting in the database. What the owner fears is not the cost, but the day the warehouse cannot ship.
1. When to do it, and when not to
If the system still runs, carries no security risk, and costs under NT$150,000 a year to maintain, it is an asset.
Good reasons to start
- The runtime is past vendor support (for example, PHP 5.x and 7.x are fully EOL) and vulnerabilities cannot be patched
- The original developer has folded or gone silent; one field change means three weeks and NT$50,000
- No interfaces, so the website, ERP and LINE live in silos and staff re-key data more than two hours a day
- Columns named remark1 to remark9, dates stored as text; reports take 8 minutes and 20 concurrent users stall the system
Not a fit
- An acquisition or pivot within six months, with the process itself still undecided
- Only one or two rough features that an add-on tool can fix
- Nobody can explain the current process and no internal owner will be assigned
- A budget under NT$200,000 paired with an expectation of total renewal — that only produces a second system to be rebuilt
2. Four options compared
| Option | Upside | Downside | Cost |
|---|---|---|---|
| Keep it alive: patch the runtime only | Fastest, 2–4 weeks | Symptom relief; breaks again within two years | NT$60,000–150,000 |
| Move to a package or SaaS | Maintenance outsourced, updates free | Process bends to the software; limited customisation | NT$36,000–300,000/yr + NT$100,000 onboarding |
| Big-bang rewrite: cut over in one day | Cleanest architecture | Highest risk; every problem lands the same day | NT$800,000–3,000,000 |
| Strangler-fig phased replacement | Roll back any time, pay in stages, no downtime | Higher parallel-run cost, longer project | From NT$180,000, in 3–5 stages |
Nine out of ten projects take the fourth path. Microsoft lists it as an official migration pattern (Strangler Fig Pattern): put a facade between old and new, route traffic module by module, until the legacy system carries none.
3. Process and deliverables
| Stage | Time | Deliverable | Tools |
|---|---|---|---|
| 1. Audit and inventory | 2–3 wks | Architecture map, row counts per table, dirty-data ratio | DBeaver, Notion |
| 2. Interviews and module split | 1–2 wks | MoSCoW priority list, staged cutover plan | Miro |
| 3. Cleansing and mapping | 2–4 wks | Field mapping sheet, dedupe rules, scripts | pandas, SQL |
| 4. First module build | 4–8 wks | UI mockups, API docs, staging site | Figma, Laravel/Next.js |
| 5. Dual write, parallel run | 4–8 wks | Dual-write mechanism, daily diff report | Scheduled scripts, Grafana |
| 6. UAT and training | 2 wks | Sign-off records, SOPs, training recordings | Notion |
| 7. Cutover and archival | 1 wk | Cutover runbook, rollback plan, read-only archive | Cloudflare, UptimeRobot |
Stage 5 is the one that matters: both systems write, a job compares the numbers daily, and only 14 consecutive days of zero variance authorise cutover. That is the only real insurance behind the phrase "no downtime".
4. Real cost breakdown
- Audit and inventory: NT$35,000–80,000 (credited against development)
- Entry tier (one core module plus migration): NT$180,000–350,000
- Standard tier (3–5 modules, two months parallel): NT$450,000–900,000
- Full tier (full rebuild, API layer, permission redesign): NT$1,200,000–3,000,000
Hidden costs run 18–30% of the total budget:
- Duplicate hosting during the parallel run: NT$3,000–15,000/month, typically three extra months
- Data cleansing: roughly 16–40 hours to dedupe 10,000 customer records
- Extracting legacy data: NT$20,000–150,000 if the vendor withholds database access
- Re-integrating payments, logistics and e-invoicing: NT$25,000–60,000 each
- Post-launch maintenance: 15–20% of development cost per year; training NT$8,000–15,000 per session
5. Reality vs. expectation
| Clients assume | What actually happens |
|---|---|
| Export, import, done over a weekend | 8–25% of legacy data is dirty; cleansing often takes 3x longer than the migration itself |
| Just rebuild what the old system does | At least 30% of features have gone unused for three years; copying them relocates the technical debt |
| Everything speeds up on day one | Productivity dips for two weeks and only returns to baseline in weeks 4–6 |
| The old system can be switched off immediately | Accounting, audit and customer complaints need 6–12 months of read-only access |
6. Five traps and how to avoid them
- No freeze period: the legacy system keeps changing fields and the mapping sheet expires daily. → Sign a feature-freeze agreement; bug fixes only.
- Letting the vendor decide cleansing rules: only sales knows whether two records are the same customer. → The client owner signs off each rule in writing.
- No rollback plan: when cutover goes wrong there is nowhere to go. → The runbook must state the hour after which you revert to the legacy system.
- Personal data exposed on staging: testing with production data breaches the security duty under Taiwan's Personal Data Protection Act. → Staging always uses de-identified data.
- Migrating every module at once: you save on the parallel run and concentrate all risk in one day. → Move the reporting module first.
7. The 90-day roadmap
- Day 30: zero variance between old and new, error rate on critical flows under 1%, uptime at or above 99.5%
- Day 60: 20–35% less operator time, reports down from minutes to seconds, re-keying eliminated
- Day 90: second module cut over, legacy system read-only, monthly labour savings and ROI payback quantified (typically 14–26 months)
8. Decision checklist (6 or more ticks: start)
- ☐ Is the runtime past vendor support?
- ☐ Has the original vendor folded or priced unreasonably?
- ☐ More than an hour a day spent re-keying?
- ☐ Told "not possible" on new requirements more than three times?
- ☐ Did a system failure affect shipping in the past year?
- ☐ Unable to obtain a full database backup?
- ☐ No API and no CSV export?
- ☐ Can you assign an owner for 4 hours a week?
- ☐ Can the budget run to NT$200,000 across three stages?
- ☐ Will the owner attend acceptance sessions personally?
9. FAQ
Q1: Is downtime unavoidable, and how long?
With a phased replacement, cutover usually takes 2–4 hours, scheduled for early Sunday morning. The length of the window matters less than whether 14 consecutive days of zero-variance dual-write validation were completed first; skipping that step makes "no downtime" a gamble.
Q2: What if the vendor refuses database access?
Start with the data-ownership clause in the contract — the data is yours, the code is theirs. If they still refuse, request CSV exports, extract table by table through print functions, or scrape your own admin panel. The most extreme case we handled reconstructed 30,000 records from PDF reports.
Q3: How do you prove no data was lost or corrupted?
Three layers: row-count comparison per table, sum comparison on key monetary columns, and manual field-by-field checks on 30 random rows per table. All three must pass before sign-off, and the comparison report is itself a deliverable.
10. Next step
ScriptWalker's Legacy Modernisation and Data Migration service starts at NT$180,000 and runs in stages. If you are still evaluating, begin with the System Audit and Data Inventory (from NT$35,000, 2–3 weeks): architecture map, data-health report and a staged proposal, with the fee credited in full against development. If the audit says do not rebuild, we will say so.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p
Include your system name, its age, how many people use it daily, and your three biggest pain points; we reply with a tiered estimate within two working days.