What drives custom software migration cost in 2026?
Custom software migration cost in 2026 is driven by four compounding variables: source data complexity, target platform choice, integration scope, and historical data volume. PCG provides a fixed-price estimate after a source audit, not before. The free initial consultation determines whether the audit is the next sensible step.
Most CFOs encounter the question of migration cost the same way: a legacy system is failing, a vendor proposal arrives with a number attached, and there is no framework for assessing whether that number reflects the actual work required. The number itself is not the problem. What CFOs lack is a framework to evaluate it. This article describes the four variables that move a migration cost up or down, how a CFO should think about each one, and how PCG arrives at a fixed-price estimate after the source audit phase.
Phoenix Consultants Group has executed conversion, migration, and integration projects since 1995, with zero data loss on record across hundreds of completed engagements.1 The patterns described below come from that production history. The framework applies equally to a Microsoft Access database moving to SQL Server, a Visual FoxPro application replaced by a custom .NET Core 8 build, an Excel-based operational system consolidated into a relational database, or a legacy ERP migration to a modern platform.
What are the four variables that drive custom software migration cost?
Every custom software migration cost decomposes into four categories. A change in any one of them moves the total project number. CFOs who understand the four can interpret a vendor proposal, identify what assumptions the vendor has made, and ask the right questions before signing. The categories are not theoretical. They map directly to the work a migration team performs from the source audit through to post-cutover reconciliation.1
Source data complexity
Schema documentation, data quality, referential integrity, undocumented relationships, and the number of source systems involved.
Target platform choice
SQL Server on-premise, Azure SQL, AWS RDS, or another destination. Each carries different schema, security, and operational requirements.
Integration scope
How many systems must connect to the destination, whether APIs exist, and whether the connection is real-time or batch.
Historical data volume
Record counts, years of history retained, physical storage size, and the number of fields requiring transformation per record.
The four variables are not independent. They compound. Higher source complexity increases the time required to map fields to the target platform. Larger integration scope extends the testing window. A bigger historical data volume amplifies the impact of every transformation rule that must run against every record. Any vendor estimate that addresses only one or two of the four is incomplete by definition.
How does source data complexity change the cost equation?
Source data complexity is the single variable that most often determines whether a migration estimate proves accurate. The first signal of complexity is whether the source schema is documented. A SQL Server database with current entity-relationship diagrams, defined foreign keys, and a consistent naming convention is materially less expensive to migrate than an Access database where relationships exist only as conventions inside application code that has been modified by three developers over fifteen years.
Data quality is the second signal. Source systems that enforce required fields, constrained value lists, and referential integrity at the database level produce migration-ready data. Legacy systems that allowed users to type free text into fields that were supposed to be controlled vocabularies produce data that must be cleaned before migration. The cleaning is part of the migration work, and it is unavoidable: data that arrives at the destination without cleaning behaves incorrectly in the new system because the new system does enforce the rules the old one did not.1
The third signal is the number of source systems. A migration from one consolidated Access database is simpler than a migration that must integrate three departmental spreadsheets, an Access database, and a legacy desktop application into a single destination schema. Each source system requires its own audit, its own mapping, and its own transformation rules. The total work does not scale linearly with the number of sources because conflicts between sources must also be reconciled.
Documented and clean
Current schema documentation, defined foreign keys, enforced data types, consistent naming, single source system, controlled vocabularies for code fields.
Undocumented and inconsistent
No schema documentation, relationships embedded in application code, free-text fields where structured data was expected, multiple source systems with overlapping data, original developer unavailable.
How does the target platform choice affect total project cost?
The destination platform sets the upper bound on what the migration can achieve and the lower bound on what the migration must build. PCG currently builds on .NET Core 8 with SQL Server as the default stack, with deployment options that include on-premise SQL Server, Azure SQL Database, and AWS RDS. Each option carries different operational and cost implications that the CFO should evaluate as part of the migration planning, not after it.
SQL Server on-premise places the data inside the buyer's infrastructure. There are no recurring per-database hosting fees, and the data location decision is fully controlled by the organization. The tradeoff is that the buyer remains responsible for backup, patching, and hardware capacity planning. For organizations with existing Windows server infrastructure and IT staff already managing SQL Server, on-premise often produces the lowest total cost of ownership over a 5 to 10 year horizon.
Azure SQL Database and AWS RDS shift operational responsibility to the cloud provider. Backup, patching, and hardware capacity are handled by the platform. The tradeoff is a recurring monthly cost that scales with database size and compute capacity. For organizations without existing Windows server infrastructure, distributed teams that need multi-location access, or businesses scaling rapidly enough that hardware procurement becomes a constraint, cloud hosting often justifies the recurring cost.2
The target platform choice also determines the schema constraints the migration must satisfy. A SQL Server destination enforces referential integrity, data types, and constrained value lists that the source system may not have enforced. The migration must conform every source record to the destination schema before loading. This conformance work is part of the migration cost, and it varies with how far the source diverges from the destination requirements.
How does integration scope move the number up or down?
Integration scope is the variable most often underestimated in vendor proposals. The relevant question goes beyond whether the destination will receive data from the source. Buyers must also define which other systems must exchange data with the destination after migration is complete, on what frequency, in which direction, and under what reliability requirements.
A migration that produces an isolated destination database, with no ongoing connection to other systems, carries no integration scope. The migration completes, the new application runs, and operations continue. This is the simplest scenario. It is also the least common in 2026, when most mid-market businesses operate with multiple connected systems that exchange data continuously.
A migration that requires connection to one external system through a documented REST API carries moderate integration scope. PCG's work is to write the connector, define the data flow direction and schedule, build the error handling for connection failures, and document the integration for ongoing support. Modern systems with current API documentation produce predictable integration timelines.
A migration that requires connection to a legacy system without an API, or that requires PCG to build an API for the new system to expose data externally, carries the highest integration scope. PCG accesses the underlying database directly using ODBC or native drivers when no API exists, or builds custom extraction layers for systems that expose no programmatic interface at all. Legacy applications built before REST APIs existed are not a barrier to integration, but the work of building the integration layer is part of the migration cost.1
The four variables compound. A migration with high source complexity, a cloud destination, three integrated systems, and twenty years of historical data is not four times as expensive as a simple migration. The interactions between variables produce a multiplier effect that only a source audit can quantify.
How does historical data volume influence the cost of a migration?
Historical data volume affects migration cost through three mechanisms that compound. The first is processing time. Every record in the source system must be read from the source, run through validation and transformation rules, and then loaded into the destination. A migration of one million records runs longer than a migration of ten thousand records, and the longer the migration runs the more rigorous the parallel testing must be to confirm the production cutover will complete within the available maintenance window.
The second mechanism is data quality remediation. Larger historical datasets carry more accumulated data quality issues simply because they contain more records, more years of variation in how data was entered, and more legacy decisions about field meanings that have changed over time. A migration that retains twenty years of history carries more cleaning work than a migration that retains five.
The third mechanism is reconciliation. Post-migration reconciliation compares source record counts and key field values against destination records.1 The reconciliation effort scales with data volume because the reports must produce meaningful comparisons across the full dataset, not against a sample. Reconciliation surfaces silent failures that pre-migration validation missed, and the time required to investigate and resolve any discrepancies scales with the size of the dataset being reconciled.
A CFO who is planning a migration should ask the operational team a specific question before requesting a vendor estimate: how many years of historical data must move, and how many years could remain accessible in read-only archive without active migration? Retaining only the active operational window in the new system, while preserving the historical archive in a read-only location, often produces a meaningful reduction in migration cost without compromising business continuity.
What hidden costs do CFOs underestimate when scoping a migration?
The line items that appear in a vendor proposal are the visible costs. Hidden costs are the operational realities that the proposal does not invoice but that absorb staff time, defer revenue, or extend the project beyond the contracted window. Four hidden costs recur across migration projects.
The first hidden cost is internal staff time during discovery and validation. A migration project requires operational subject matter experts to answer questions about field meanings, business rules, and data quality decisions. The time spent in interviews, mapping reviews, and user acceptance testing is real labor that the vendor proposal does not charge for. CFOs who budget only the vendor cost miss the internal cost, which is typically 15 to 30 percent of the project effort when measured in hours.
The second is data quality remediation. Source systems that have been running for years without enforced rules accumulate quality issues. The migration surfaces every issue. Some are minor and can be corrected during transformation. Others require operational decisions: which value is correct when the same customer record exists twice with slightly different addresses, or which date is authoritative when two systems disagree. These decisions require operational judgment and absorb time.
The third is integration recertification with downstream systems. If the destination system feeds data to a reporting platform, a regulatory submission, or a partner system, those downstream consumers must validate that the post-migration data still meets their requirements. This validation is sometimes documented as a separate compliance task, and it carries its own timeline.
The fourth is post-cutover operational learning. New systems behave differently from the old one. Staff who have used the legacy system for years will need time to adapt to new workflows, even when the new system is objectively better. Training is part of the vendor cost, but the productivity dip during the first weeks of operation is not. CFOs who account for this learning curve in their financial projections see fewer surprises in the first quarter after cutover.
Speak directly with the engineer who would scope your migration
A free 30-minute consultation to evaluate which of the four variables apply to your situation. No obligation, no sales handoff.
How does PCG estimate a migration project, and when in the process does the number get fixed?
PCG does not quote a fixed price before the source audit. The reasoning is operational, not commercial. A migration estimate produced before the source audit is either inflated to cover unknown risks or committed against assumptions that may not match the actual source system. Neither outcome serves the buyer. Information gathered during the source audit is what makes a fixed-price estimate accurate.
PCG's process moves through five phases. Each phase produces a deliverable the buyer reviews before the next phase begins, and the fixed-price commitment for the full migration is made at the end of the second phase, not at the beginning of the first.1
Before the fixed price is set
Source audit phase
- Free initial consultation with the engineer who would scope the project
- Complete source schema inventory: tables, fields, relationships, constraints
- Data quality assessment with identified remediation requirements
- Source-to-destination field mapping specification
- Estimated transformation rule count and complexity
- Documented integration scope with named external systems
After the audit completes
Fixed-price commitment
- Fixed-price estimate for full migration based on actual measured scope
- Project timeline with phase-by-phase milestones
- Defined acceptance criteria for each milestone
- Documented assumptions and dependencies
- Change order process for scope additions identified later
- Reconciliation report deliverable at project completion
A vendor who quotes a fixed price without conducting a source audit is quoting against assumptions, not against the actual system. CFOs should treat that quote as preliminary, not committed.
PCG has been executing migrations on this methodology since 1995. Hundreds of Microsoft Access to SQL Server migrations, dozens of legacy ERP transitions across Sage, Great Plains, and Peachtree platforms, and operational system replacements for industrial, environmental, healthcare staffing, and airport operations clients all follow the same audit-first sequence. The fixed-price commitment is the output of the source audit, never the input to it.1
Find out which variables apply to your migration
A free 30-minute consultation, followed by the source audit if it is the right next step. The fixed-price estimate comes after the audit.
A migration estimate depends on what the source system actually contains, not on what the documentation claims it contains. The source audit measures real data volume, identifies undocumented relationships, and surfaces data quality issues that need correction before migration. A price quoted before the audit either includes a large risk premium to cover unknowns or commits PCG to a scope that may not match reality. After the audit, PCG provides a fixed-price estimate based on the actual work required.
PCG reverse-engineers the source schema directly from the database structure rather than relying on documentation. The audit maps every table, field, relationship, and constraint from the database itself. The absence of the original developer extends the audit phase but does not prevent a complete and accurate migration.
Yes. PCG's methodology runs the migration against a parallel destination environment while the source system remains the operational master. The team continues working in the existing system during migration and validation. Cutover happens only after reconciliation confirms accuracy and the buyer's team approves the results.
A fixed-price quote commits the vendor to deliver the agreed scope for a defined number. A time-and-materials quote charges by the hour with no upper bound. Fixed-price is preferable for migration projects because it forces the vendor to do the source audit work upfront. PCG provides fixed-price estimates after the source audit so the buyer knows the cost before committing to the migration.
Three safeguards prevent data loss. Pre-migration validation catches records that would fail destination schema rules before they move. A quarantine log holds failed records for review rather than silently dropping them. Post-migration reconciliation compares source record counts and key field values against destination records. No migration is considered complete until reconciliation confirms zero unresolved discrepancies.
Three deliverables: the migrated data in the destination system, the migration documentation package, and a reconciliation report confirming data integrity. The documentation includes the source audit results, the field mapping specification, the transformation rules applied, the quarantine log with resolution notes, and the post-migration reconciliation report. The package provides a complete audit trail of what moved and how it was transformed.
Yes. PCG's phased methodology produces stable checkpoints at the end of each phase. The source audit deliverable is usable on its own. The schema mapping and transformation rules document remains valid for later resumption. The parallel environment can be paused and reactivated. A pause adds re-validation time when work resumes but does not invalidate earlier phases.
1 Phoenix Consultants Group, Conversion, Migration and Integration service page. phxconsultants.com
2 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
This article is informational and reflects PCG's experience executing custom software migrations for mid-market businesses since 1995. It is not legal, regulatory, or financial advice for any specific situation. For guidance tailored to a particular migration scope, source system, or compliance context, contact Phoenix Consultants Group directly.