Migration projects are often initiated with the objective to save on operational cost. And due to the ridiculous price of keeping a mainframe going the business case is often very attractive. The savings from this alone leads to the decision to do a one-to-one conversion to a lower cost platform such as .NET. From my experience this is the first mistake.

One-to-one conversions do not exist.

The temptation to extend the system as it is being rewritten is simply too great, and many times there will be ample opportunity to simplify it and remove bugs as well.

The problem in migrating mainframes is knowing what the old system does and more importantly why.

Many times it will include a number of business rules that may or may no longer have any relevance. They may be hacks to compensate for a specific data quality issue 15 years ago. Or they may be of critical importance even today. You will be surprise how often someone will dig out the source code to the legacy system and tell you what it is doing without being able to specify why. 

Knowing the current business requirements is the central issue.

Additionally, since mainframe systems are usually thought of as a database there is a tendency to build the new system from the database and up. Often the old system will be described in terms of its database schema and this will be used as the foundation for the new system. This is an anti-pattern. Instead we should focus on the business requirements and design a proper architecture and a new database to fit this. 

On top of this the quality of data in legacy systems is often somewhat lacking. Therefore the ability to migrate data from the legacy system to the new system is paramount. If you have any DBAs on your team you will be tempted to do the database migration by writing to the database without going trough the new application. It is important to resist this urge since it either gives you invalid data if the data quality is low, or forces you to implement the semantic validity business rule checking in both the data migration code and in the mainline application leading to duplicated effort and the possibility of inconsistencies.

Data migration should be done through the new object model. And it should evolve concurrently with the rest of the application.

To sum it up: when you do migration projects, remember these points:

• DO allocate plenty of resources to uncover the requirements.
• DO allocate some effort to do some business process reengineering to simplify things.
• DO build it iteratively - you will be surprised by how much effort goes into figuring out the requirements so it is better to learn this quickly than missing a huge deliverable much later. By learning early you have more time to adjust scope and schedule.
• DO design the system from the top-down from the business perspective, not from the database and up.
• DO include the data migration effort in the main project and deliver it incrementally.