Question 1

How much does a legacy migration cost?

Accepted Answer

From $5,000 to $30,000 USD, or A$7,500 to A$42,000. The decisive factor is how much of the old system's behaviour is only documented in the heads of the people who use it. A database with clean constraints and an API is a straightforward job. A twenty-year-old desktop application with hardcoded business rules nobody remembers is a different project, and the audit exists to find that out before the quote is fixed.

Question 2

Can you migrate everything without any downtime?

Accepted Answer

For most systems, no, and anyone promising zero downtime on a legacy migration is overselling. What we can do is keep downtime to a planned window, usually a weekend, by running the new system in parallel first and cutting over once the reconciliation report passes. For systems that genuinely cannot stop, we build a dual-write bridge that syncs both directions during transition. That bridge is extra work and it carries its own failure modes.

Question 3

What if the original developer is gone and there is no documentation?

Accepted Answer

That is the normal case, not the exception. We read the code and the database, then interview the people who use the system daily, because they know the workarounds that were never written down. This discovery phase typically takes two to four weeks. Skipping it produces a new system that looks correct and quietly drops the one rule the business actually depends on.

Question 4

How long does a migration take?

Accepted Answer

Three to nine months for a business-critical system. Audit and mapping take the first month or two, build takes two to five, then parallel running adds another month or two. Rush a migration and you find the missing records in the first week of real use, at the worst possible time. If you have a hard deadline, tell us at the start so we can scope to fit it rather than discovering the problem late.

Question 5

Will the historical data come across intact?

Accepted Answer

Transactional data migrates well when the schemas are sane. What causes trouble is data that was never valid in the first place: orphaned foreign keys, dates stored as text, currency amounts with inconsistent rounding, and free-text fields standing in for structured data. We report every anomaly we find and agree a rule for each one. Some records cannot be salvaged automatically, and they go into an exceptions file for your team to resolve.

Question 6

Who owns the new system and the migration scripts?

Accepted Answer

You own everything: the new application, the migration scripts, the mapping documents and the reconciliation reports. The old system stays running until you are satisfied, and we do not decommission anything until you sign off in writing. If your team wants to run the final migration themselves using our scripts, we will support that.

Question 7

Do you keep the old system alive during the transition?

Accepted Answer

Yes. For the parallel period we patch critical bugs in the old system so it does not fall over mid-migration, though we will not add features to it. That patching is charged at support rates. Once you have signed off and the new system has run clean for a month, we help you archive the old data and shut it down.

Legacy system migration