Article series on replacing legacy software, part 2: data and data migration

Article series on replacing legacy software: data and data migration

When organizations replace legacy software, the biggest technical challenge is safely moving decades of business-critical data from old systems to new ones without losing information, corrupting records, or disrupting daily operations.

Think of data migration like moving a library that's been operating for 25 years. The books (your data) have been organized by librarians who've long since retired. Some books are misfiled, others have pages missing, and the catalog system uses a numbering scheme nobody fully remembers. Now you need to move everything to a new building with a completely different organization system, and the library can't close during the move.

After reading this article, readers will understand how to approach data migration when replacing legacy systems, what challenges they'll face, and practical strategies to preserve business continuity during the transition.

‍

The data migration dilemma

Legacy systems accumulate data inconsistencies over decades of use. What starts as a clean database gradually develops gaps, duplicates, and edge cases that the original designers never anticipated. Users adapt their workflows around these quirks, creating informal business rules that exist nowhere in documentation.

When Eli5 evaluates legacy systems for modernization, data quality emerges as the primary migration bottleneck. Systems that have run reliably for years suddenly reveal fundamental data integrity issues when subjected to modern validation rules.

"The main problem is that our new system has all these capabilities and expects data to be consistent," explains Kishan, CTO at Eli5. "But data that has been created by somebody else in a legacy system might not have the same constraints. So there's a lot of gaps, there's a lot of missing data, there's a lot of inconsistencies, and that hurts the migration."

The two-path strategy

Organizations face a fundamental choice when preserving legacy data: integrate or migrate.

Integration approach: Build an integration layer that leaves existing systems untouched while creating APIs for new applications. This approach minimizes risk and allows rapid development of new features without disrupting established workflows.

The integration layer acts as a translator between old and new systems, handling data format differences and business rule translations. Users continue working with familiar processes while gaining access to modern functionality.

Migration approach: Move data completely from old systems to new ones. This path offers long-term benefits like reduced maintenance costs and unified data architecture, but requires extensive data cleanup and validation.

Most organizations begin with integration for quick wins, then gradually migrate non-critical data pieces before tackling core business functions.

Data archaeology: working with undocumented systems

Legacy systems often outlive their creators. The original developers have moved on, documentation is incomplete, and business logic exists only in the code itself.

"Once or twice we've encountered cases where companies have been running for years and it was created by a person in the company in the beginning," Kishan notes. "Nobody can touch it except for one person. Normally it's companies that work with an access database or a database that runs locally in a computer somewhere under somebody's desk."

When facing these archaeological challenges, Eli5's approach focuses on collaboration and systematic discovery:

1. Business logic reconstruction: Work closely with long-term employees to understand how the system evolved and what business rules emerged over time
2. Data pattern analysis: Examine the data itself to infer missing business rules and constraints
3. Gradual understanding: Build knowledge incrementally rather than attempting complete documentation upfront

The data quality challenge

Legacy data migration reveals quality issues that may have been invisible during normal operations. The most common problems include missing data where fields that should contain values are empty or null, inconsistent formats such as dates stored as text or addresses following different conventions, orphaned records that reference data no longer in the system, and business rule violations where old data conflicts with current validation requirements.

These issues compound over time as systems evolve without comprehensive data governance.

The solution requires both automation and human judgment. "Either you drop everything and just don't migrate it because it's not according to what you want it to be, but normally that's not acceptable," Kishan explains. "So the secondary step will be to actually try to fix the data, which is a manual intervention."

Migration planning and execution

Successful data migration requires scenario-based planning with clear assumptions and fallback options. In the best case, data is mostly clean with predictable patterns and minimal gaps. The middle scenario involves some data quality issues that can be resolved through automated cleanup or inference from related data. The worst case requires significant business decisions about what to preserve versus what to rebuild when data gaps are too extensive to fill.

The timeline for migration varies dramatically based on data complexity. Simple migrations might complete in weeks, while complex enterprise systems can require months of data preparation.

"I don't think there is a clear migration path that we can set for anyone as a baseline," Kishan observes. "Right now we are on a migration project that has been running for 3 months, but the main problem is data inconsistencies."

Phased migration strategy

Enterprise-level systems require careful orchestration of old and new system coexistence. The approach depends on how deeply the legacy system is integrated into business operations.

For systems that control critical business processes, the migration follows a cautious path:

1. Identify non-critical components that can be migrated first without affecting core operations
2. Test migration processes on isolated data sets to validate cleanup procedures
3. Migrate peripheral functions while keeping core systems intact
4. Gradually transfer critical functions only after validating that migrated components work correctly

"What you do then is try to migrate non-critical parts piece by piece and don't touch the entire critical system until you know for sure that all these small parts that you did migrate work separately," Kishan explains.

AI and automation opportunities

Modern migration projects can leverage AI for data processing, but human oversight remains essential. AI excels at pattern recognition and can assist with data standardization by converting inconsistent formats to standard patterns, gap inference using related data to fill missing information where context provides sufficient certainty, and quality detection to identify data anomalies and inconsistencies automatically.

However, AI limitations become apparent with legacy data's distributed and inconsistent nature. "Legacy databases are normally very distributed across a lot of different database tables or rows," Kishan notes. "There's no modernization that has been applied to this data. So that is also very difficult for them to interpret."

The software modernization industry continues growing as more systems reach end-of-life. However, the fundamental challenge remains: legacy data doesn't fit neatly into modern system expectations.

While AI agents may eventually handle more migration tasks, current technology limitations around context windows and data inconsistency mean human expertise remains crucial for business-critical migrations.

The most successful migrations combine systematic planning with flexible execution, treating data migration as both a technical and business challenge that requires deep collaboration between technical teams and business stakeholders.

‍

Planning data migration

When approaching legacy data migration, consider these key factors:

1. Assess data quality early through sampling and analysis before committing to migration timelines
2. Plan for multiple scenarios including data cleanup costs and potential business rule changes
3. Consider integration first for quick wins while planning longer-term migration strategies
4. Invest in collaboration between technical teams and business users who understand how the data is actually used

The goal isn't perfect data migration but rather preserving business continuity while enabling future capabilities. Sometimes the best approach is accepting imperfect data rather than perfect migration that never completes.

‍

What's next in this series

‍Future articles will explore specific aspects of legacy software replacement:

• Decision frameworks for choosing between the six replacement approaches
• User experience redesign for business-critical systems
• Vertical SaaS alternatives to custom rebuilds
• AI agents and the future of enterprise software architecture

‍