A broad view of organisational data is vital for management reporting, business intelligence, analytics and decision support. But what happens when critical data from important lines of business is locked up in a legacy Db2 system, technically incompatible with modern data management solutions that hinge on Microsoft technologies?
In our experience, this scenario is more common than you might think. Whether you choose to migrate to SQL Server, Oracle, PostgreSQL or even relational Db2, it’s worth considering these three best practices we’ve developed to help ease the transition to a standard relational database management system (RDBMS).
Whilst the Db2-to-relational transition is anything but like-for-like, there are going to be far more similarities than differences between the source and target architectures. Design the target database layout with the functional aspects of the source in mind. Create required objects with the same name and data types as source objects. This creates familiarity and ease of querying without the need to learn new mappings and reduces time to productivity when mainframe Db2 is decommissioned. It may pay dividends to establish patterns or reuse existing best practices like parent-child package executions, execution control via configurations and final execution from a service like SQL Server Agent as opposed to direct package execution from third parties, package templates, etc.
An extension of smart architectural considerations, development best practices can make a huge difference when migrating mainframe Db2 to relational. Whether you're implementing new and more efficient standards in the target environment or even converting Db2 timestamps to equivalents in the RDBMS, keeping the development environment that will be administered against the new database will save tons of time and headaches down the road.
Implementation and maintenance
It is vastly important to keep the services that depend on the database in mind during the migration process. Taking Db2 to relational isn't simply about a conversion exercise, it is about migrating to a modern environment that can more easily and more efficiently interact with other business-critical services. Liberating legacy data for consumption in modern BI systems is an exciting endeavour, but don't let it eclipse the importance of interoperability with other less exciting systems that rely on the data you're migrating to operate day-in and day-out.
Companies of all sizes are grappling with ageing, complex systems that are costly to maintain and too inflexible to support new business initiatives. Most vendors are more concerned with selling new systems than helping to retire old ones. It can take a lot of effort to move data off the old system, archive the application’s data and decommission the supporting infrastructure. It can be a challenging project, but with a little help and a few pointers, it doesn't have to be impossible.