A database switch raises questions

This is often when doubt sets in. After all, the database contains the heart of your system. All the information you need on a daily basis is stored there. In the case of IBM Maximo, this includes work orders, asset information, fault history and reports. The step to another database can quickly feel like a risk.

It is therefore not surprising that concerns immediately come to the table as soon as a database migration is discussed. What are the biggest fears and how can you address them?

1. Is my database too large for a migration?

Standard IBM tools are available for database migrations. These first convert a database into a text file that captures the database schema and the data. The database is then rebuilt on the new platform from that file. With smaller databases this usually works directly.

For large databases, a split approach works better. The database schema – the framework of the database – and a portion of the smaller tables are transferred using the IBM tool. This puts the foundation of the database in place on the new platform.

Larger tables then receive separate treatment, using specially developed tools that transfer tables with many records in batches. Tables with large BLOB and CLOB fields receive extra attention. By processing these tables separately and in a controlled manner, even a large database remains fully migratable.

2. Will I get all my data across exactly as it is?

A well-known example is case sensitivity. Many Oracle environments use case-sensitive databases, while SQL Server often does not. As a result, values such as ABC123 and abc123 can exist alongside each other in one database, but be treated as duplicates in another. Situations like these need to be identified before the migration.

Differences can also arise with data types and field definitions. Think of text fields with a different maximum length, numeric fields with different precision, or date types that are stored slightly differently. During the migration, the tool converts the data to the correct format.

After the migration, the data itself is checked. Record counts are compared, and for critical tables the content of fields is also verified. This confirms whether the data in the new database matches the original situation.

3. Will the database syntax be translated correctly?

When moving to a different database platform, this platform-specific syntax needs to be translated. SQL may look the same everywhere, but functions and constructions differ by database type (Oracle, MS SQL, DB2). A function or data type that exists in Oracle often has a slightly different equivalent in SQL Server or DB2.

That is why a migration starts with an inventory of the database objects and query structures in the existing database. Standard constructions can usually be converted automatically. For database-specific functions or custom objects, an adjustment is often needed to preserve the same logic on the new platform.

This keeps the database functioning exactly as it should, even when it runs on a different platform.

4. Will my database performance stay the same?

For this reason, a database migration starts with an analysis of the environment in which the database will run. What servers are available? How much processing power and memory will be needed? And how much capacity will you require as the database continues to grow in the coming years? This creates a clear picture of the infrastructure needed for the new database platform.

Next comes an analysis of how the database itself is used. Queries largely determine how quickly a system responds. The where clauses used, for example, play an important role. The more efficient the query, the faster the result is available without placing a heavy load on the system.

By taking both the infrastructure and query usage into account, the database after migration will not only function in the same way, but its performance will also align with the actual usage of the system.

5. Will my system be offline for too long?

That is why the migration is first carried out completely in a test environment. All steps are performed there: transferring the database, starting up the new environment and performing the data checks. This makes it clear how much time each step takes and where any bottlenecks may lie. A detailed migration plan is then created based on these insights. Because the full migration has already been executed, the risks and the duration of the transition are known in advance.

The actual migration then takes place at a time when your organisation will be least affected, for example during a maintenance window or outside peak hours. Because the steps are known and the timing has been tested beforehand, the transition runs in a controlled and predictable manner.

Database migration requires experience

At Gemba we have extensive experience migrating databases for enterprise systems such as IBM Maximo and other platforms. Based on that experience, we have developed an approach and toolset with which even large and complex databases can be migrated in a controlled and predictable way. This allows us to address the main concerns of a database migration step by step.

Want to discuss the migration of your database? Get in touch with Wouter Schouten on +31 (0)6 52 68 37 43 or w.schouten@gemba.nl.