When Migrating Old System Data to a New App, Is It Reasonable for the Outsourcing Vendor to Say It's Outside the Development Scope?

Bottom line first: In 2026 outsourcing delivery, migrating legacy system data to a new app is generally not automatically included in the custom app development fee. Unless the contract or requirements document explicitly mentions historical data import, field mapping, and acceptance criteria for migration, it is common for the outsourcing vendor to price data migration separately or exclude it from the development scope. Instead of arguing about whether this is reasonable, first clarify the data boundary, cleansing responsibilities, and acceptance standards.

Why Data Migration Falls Outside the "Development Scope"

Custom app development pricing units are usually based on pages, functional modules, and API integration. Data is expected to be entered through the new system. For legacy system data to enter the new app, you must first handle table structures, field mapping, unique identifiers, dirty data, and varying date formats—this is essentially an independent "data moving" task. Therefore, many standard pricing templates list it as an optional item.

• New feature development addresses "how data will be generated in the future," while data migration addresses "how historical data gets in."
• Projects without historical data naturally don't need migration, so many pricing templates do not include this item.
• What really affects pricing is whether the old system can export data, the number of tables, the number of records, field completeness, and whether cleansing is needed.

Three-Part Assessment: Responsibility for Migration Depends on Three Questions

Don't rush to ask the vendor "why didn't you include it in development." First check the following in order.

1. Look at the functional boundary in the requirements document: Does it mention "import old system data," "initialize historical data," or "data mapping table"? If yes and field lists are confirmed, it's in scope; if it only mentions login, list views, order placement, or other new features, it's not included. Field mapping is not a vague term—for example, which field in the old table corresponds to the new app's "username," and how the "status value" maps to the new options, must be specified.
2. Check what the old system can export: If the old system is shut down and you only have screenshots or paper documents, the vendor cannot perform a complete migration. The client must first prepare usable data files; otherwise, migration costs will be much higher.
3. Determine whether new business must carry over historical records: If balances, loyalty points, or order history must continue, migration is essential; if you only need archives, a low-cost import or offline query is an option.

The actual outcome is not limited to "the vendor does everything" or "the vendor does nothing." If the client provides a well-structured data table, the vendor handles mapping and import; if data is too messy, the client should clean it first, then discuss migration to make progress smoother.

When to Discuss Data Migration to Avoid a Passive Position

Data migration is not a last-minute task just before launch. Based on typical 2026 project delivery practices, right after prototype confirmation, you should discuss what the old system can export, which fields need to go into the new system, and who will confirm unique identifiers. If you raise it only after development is complete, the usual consequences are rewriting import scripts, milestone delays, and budget overruns.

• Requirements phase: Add "historical data must enter the new app" as a functional item and assign a data owner.
• Prototype phase: Ask the vendor to review two or three sample records from the old data to expose field mismatches as early as possible.
• Development phase: Run a test import using a subset of real data—don't wait until the full launch.
• Testing phase: Check table by table according to core business modules, and produce a reconciliation report before the official migration.

On-Site Delivery Story: A Messy Excel Delayed the Project by Three Extra Weeks

When handling real projects, the client often sends over legacy system Excel files, and the contract only says "support go-live." In one case, the constraints were: phone numbers in the Excel sometimes included area codes and sometimes not; dates were in formats like "2026/1/5" and "1月5日, 2026"; and foreign keys for order records didn't match. Halfway through the import, we found a high duplication rate and had to stop to verify line-by-line with the client. Our approach breaks migration into four steps: data sample confirmation, cleansing rule confirmation, test import, and full import. We first locked down data sources and unique identifiers at the sample stage. Even after that, the full migration took three weeks longer than expected. Based on our experience range for such projects, schedule overruns due to messy data typically range from two to four weeks, and costs commonly range from several thousand to tens of thousands of yuan. Because the contract didn't specify data cleansing, both parties shared the cost of the changes. The lesson: if you don't lock down the data source and completion criteria before work starts, the risk of rework is high.

Three Migration Options: Cost and Applicability Boundaries

• Vendor handles complete migration: Suitable when the old system has complete database documentation and clear field meanings. Typical cost range is a few thousand to tens of thousands of yuan, with a schedule increase of one to three weeks. Post-migration related queries work more seamlessly.
• Client cleans, vendor imports: Suitable when the client has someone who understands the data structure. Cost will be lower, and the schedule increases by about half a week to two weeks—but responsibility can stall on "data not clean enough," leading to disputes during acceptance.
• Static archive export: Suitable when historical data is small and only needed for archival. Export the old system as read-only attachments. Cost is usually lower than the first two, and it can be done in a day or two, but users cannot perform related queries on historical data within the app.

Selection criteria: Consider whether historical data affects users' current usage. If balances, points, and order history must continue, choose vendor-managed migration. If historical data is only for backend review, static archiving saves money. Costs and schedules for these options are experience ranges; actual quotes vary with data volume and field completeness.

Two Acceptance Gates for Migration: Rules and Rollback

Migration failures rarely come from tools—they are usually due to unclear rules. Common pitfalls include mismatched fields between old and new systems, multiple duplicate records for the same user, password fields that can't be decrypted, inconsistent timestamp precision, and broken foreign key relationships after import.

During acceptance, focus on four documents: data mapping description, cleansing rules, test import report, and reconciliation table. To define what qualifies as acceptable, you should at least be able to answer: how many records were imported for each core table, how many were skipped, why they were skipped, and whether you can roll back to the pre-migration state if issues arise.

Applicability and Boundaries: Don't Treat Migration as a Default

This article applies to: projects with an existing or running legacy system where the plan is to import historical business data into a new app. This article does not apply to: new projects with no legacy system or no historical data; scenarios where the old system is only kept as a static archive but no structured import is needed. In those cases, you don't need to worry about whether the vendor should handle data migration.

Scenarios where full migration is suitable: existing users need to query historical orders or chat logs; balances, points, or coupons need to carry over; business compliance requires a complete audit trail. Scenarios where full migration can be skipped: after the new app launches, it only displays the most recent three months of data, and historical data is kept as read-only archives on the PC; or the old system has only a few thousand records, and manual entry is faster than designing a migration plan.

A clear boundary: Migration does not mean the new and old system states are identical. Both parties should agree in advance on the checking method and time range. Financial discrepancies require manual line-by-line review and are not suitable for automated scripts alone. If the project has no old data, migration work should not occur in the first place.

Frequently Asked Questions

How much should data migration generally cost?

Based on experience ranges for small to mid-sized custom projects, costs range from a few thousand to tens of thousands of yuan, mainly depending on the number of data tables, the number of records, and whether cleansing is needed. Have the vendor quote separately for data preparation, test import, and official import for easier verification.

Is it safe to give the outsourcing vendor direct access to the old system's database?

It's risky. It's not recommended to grant production database administrator permissions. Ask for a read-only backup or sample export for verification. Include in the contract that data will only be used for migration and must not be retained after completion.

Does data from an old system in Excel also count as data migration?

Yes, but it's unstructured migration. Excel requires defining fields and unique keys first; without a unique key, duplicates are likely. The messier the fields, the higher the estimated cost and the longer the timeline.

If data is missing after migration, whose responsibility is it?

First, check the reconciliation table. During acceptance testing, both parties should verify record counts for core tables to identify where data was lost. If the vendor did not follow the confirmed migration standards, the vendor is responsible.

Before signing a contract, answer three questions: Must historical data from the old system enter the new app? Who is responsible for data cleansing? What criteria will be used for migration acceptance? Without clarity, the vendor not including migration is not unreasonable; once clarified, make migration a milestone and proceed with "data sample → test import → full import → sample verification." If the new app doesn't need historical data at all, migration shouldn't happen in the first place.