Services

Moving to a new system, how many years of old data should you migrate? Use a 'migration tiering table': move master data and the last 2–3 years of transactions, turn older records into read-only archives; migration is often 10–20% of the budget, and moving everything can double or triple the hours

2026.11.09 · 1 views
Moving to a new system, how many years of old data should you migrate? Use a 'migration tiering table': move master data and the last 2–3 years of transactions, turn older records into read-only archives; migration is often 10–20% of the budget, and moving everything can double or triple the hours
“

When replacing a system, many owners start with 'bring all the old data over.' We cover three migration myths, a reusable tiering table and hours formula, how three kinds of companies land differently, hidden costs, a vendor scorecard, a 90-day migration playbook and a decision checklist. ”

Share:

Short answer: Most small businesses only need to fully migrate master data (customers, products, open orders, stock) and the last 2–3 years of transactions, turning older records into read-only archives. Migration is typically 10–20% of the project budget; insisting on moving 10 years of data often doubles or triples the migration hours.

A 25-person hardware wholesaler is replacing an 11-year-old inventory system with a web-based one, quoted at NT$850K. The owner wants "all 11 years of orders searchable in the new system." The vendor's assessment: migration alone would take 45 working days and add NT$280K, because product codes followed different rules for the first six years and 1,900 customers were duplicated.

Myths worth breaking

Bottom line: migration is not copy-and-paste, and every extra year raises the cleanup cost.

  • Myth 1: more data is more valuable. Reality: transactions older than three years are rarely looked up but take the most time to clean.
  • Myth 2: the law requires moving everything. Reality: Article 38 of Taiwan's Business Entity Accounting Act requires keeping vouchers 5 years and books 10 years; archives can satisfy that without loading them into the new system.
  • Myth 3: keeping old personal data is safer. Reality: Article 11 of the Personal Data Protection Act requires deletion once the specific purpose ends, so migrating more means more liability.

The core framework: a migration tiering table and hours formula

Bottom line: tier every table first, then estimate hours with a formula, and the quote has a basis.

TierContentsHandling
A Full migrationCustomers, products, suppliers, open orders, opening stockClean, merge, import completely
B Recent transactionsLast 2–3 years of orders, shipments, paymentsConvert format and import
C Read-only archiveTransactions older than 3 years, old reportsDatabase backup + simple lookup page or PDF, lookup only
D Don't migrateExpired personal data, test data, temp filesDelete after sign-off, keep a log

Hours formula: migration person-days ≈ number of tables × (0.5–2 person-days per table) × dirty-data factor (clean 1.2, average 1.5, messy 2.0). For example, 30 tables at 1 day each with a 1.5 factor is about 45 person-days; migrating only the 18 A- and B-tier tables is about 27.

Three typical scenarios

Bottom line: the same table gives different answers for different companies.

  • A manufacturer on 10 years of Excel: full master data, the last 2 years of orders imported, original files archived in the cloud; about 12% of budget.
  • An e-commerce shop on an old PHP system (3,000 orders a month): members and 3 years of orders migrated; about 18% of budget with two trial runs.
  • A service business moving from SaaS to custom (15 staff): 3 years of bookings and customers suffice; about 8%, and the key is finishing before the SaaS contract ends.

Hidden costs

Bottom line: a quote line reading "data migration, lump sum" often misses these.

  • Data cleanup: merging duplicate customers and unifying codes is often 40–60% of migration hours.
  • Internal staff: someone who knows the old data needs 4–8 hours a week for 4–6 weeks to confirm mapping rules.
  • Trial runs and reconciliation: at least two trial runs, each needing 2–3 person-days to compare counts and totals.

Vendor KPI scorecard

Bottom line: these 8 questions show whether a vendor has done migrations before. Score each 0–2 and sign at 12 or more.

DimensionScores 2 when…
Data inventory firstThey looked at real samples before quoting
Tiering proposedThey suggest what not to migrate
Hours broken downPerson-days listed per table
Trial runsAt least two, with reconciliation reports
Acceptance criteriaClear tolerance for counts and totals
Rollback planCan revert to the old system if cutover fails
Personal data handlingExplains access and deletion during migration
Archive approachConcrete plan for looking up tier C data

How ScriptWalker can help, and when we're not a fit

Bottom line: migration can be priced on its own instead of buried in the build quote.

  • One-off project: data inventory and tiering recommendation, NT$20K–50K, report in 2 weeks.
  • Build including migration: quoted in person-days from the tiering table, usually 10–20% of the project.

We're not a fit if you need it done in a week with no trial runs, can't provide sample data, or are moving a large ERP's general ledger (bring in the original vendor and your accountant).

Transition playbook

Bottom line: start migration before development ends, and run the first trial no later than six weeks before launch.

  • Month 1: inventory tables, pull samples, finish the tiering table, and name an internal data owner.
  • Months 2–3: clean data, run the first trial and reconcile counts and totals, then a second trial two weeks before launch.
  • Day 90: cut over, confirm archive lookup works, and delete tier D data as planned with a log.

Decision checklist

Bottom line: if you tick 6 or more, it's worth starting to plan.

  • ☐ Do you know how many tables the old system has?
  • ☐ Can you provide at least 100 real sample records?
  • ☐ Are customers or products duplicated?
  • ☐ Has anyone looked up an order older than three years in the past year?
  • ☐ Has your accountant confirmed how books and vouchers will be kept?
  • ☐ Does the quote list migration hours separately?
  • ☐ Does the contract state trial runs and acceptance thresholds?
  • ☐ Is there a rollback plan if cutover fails?

FAQ

How many years of old data should move to a new system?

For most small businesses, master data and the last 2–3 years of transactions. Older data goes to a read-only archive you can still search.

How is data migration priced?

Usually 10–20% of the project budget. Estimate it as tables × person-days per table × a dirty-data factor; messier data and more years cost more.

Do accounting books have to be loaded into the new system?

Not necessarily. Taiwan requires vouchers kept 5 years and books 10 years, which an archive can satisfy; confirm the method with your accountant.

Next step

Unsure how much old data to move? Send us a table list or an export sample. ScriptWalker (a Taiwanese Laravel/Flutter custom development studio) offers a free 30-minute consultation with a first estimate of tiers and migration hours.

Share: