AS400 to IBM Power 11 Partners
(888) 682-5335

Database conversion and data migration to IBM Power

Separate moving data from changing the database engine

Choose a data-transfer approach that fits the source engine and approved Power target. Account for SQL, extensions and application behavior before estimating the outage.

Choose the source database

Database work for a non-IBM to Power move
Source database or changeAssessment focus
Oracle DatabaseExact certified platform, release and cross-platform transfer procedure.
SAP HANASAP revision rules, certified configuration and supported copy or replication procedure.
PostgreSQLLogical transfer plus target extensions, locale, roles and version compatibility.
MySQLLogical transfer plus engine, plugin, SQL-mode and release checks.
SQL ServerRetained x64 engine or an explicitly approved engine and application conversion.
Changing to Db2 or Db2 for iA new engine and application design, not an automatic consequence of buying Power.

Define the database change precisely

A same-engine migration preserves the database product while changing its host or release. An engine conversion changes the product and can affect SQL dialect, data types, stored procedures, security, jobs and application support. Those are different estimates and acceptance plans.

Record who owns application changes and which supplier supports the final combination. An exported table is only one part of an operational database service.

PostgreSQL logical transfer can cross architectures

PostgreSQL documents pg_dump as a way to transfer across machine architectures. Qualify source and destination versions and use an appropriate client/procedure. Treat physical backups as a different method with their own compatibility requirements.

Recreate required roles and privileges, extensions, tablespaces, locale and collation behavior. Verify target builds for native extensions. Rehearse restore, statistics collection, query behavior and application reconnects with production-like data. A new CPU architecture does not solve an unsupported extension.

MySQL logical backups separate SQL data from physical files

MySQL documents logical backups as portable while physical copies depend on hardware and other compatibility constraints. Choose a procedure supported for the actual source/target releases and storage engines. Do not assume copying a data directory is equivalent to a logical conversion.

Inventory character sets, collations, SQL modes, authentication plugins, routines, events and replication dependencies. Qualify the target package and support arrangement on Power. A MySQL-to-MariaDB change needs its own product and application compatibility review.

SQL Server to another engine requires application conversion

SQL Server on Linux is x64 software, as explained in the Windows and SQL Server guide. An approved Power project can retain that database elsewhere or convert to a different engine supported by the application.

For an engine change, inventory T-SQL procedures, SQL Agent jobs, linked servers, SSIS/SSRS dependencies, identity/sequence behavior and collation-sensitive queries. Test replacement behavior with the application owner. A clean table import does not prove those functions still work.

Db2 and Db2 for i are distinct destination choices

Select the database product and supported application combination explicitly. Moving a non-IBM workload into Db2 for i also introduces the IBM i application environment and its design and licensing decisions. It is not a way to boot an HP-UX or Windows application unchanged.

Map schema, data types, procedures, batch jobs and integrations to the selected product. Use vendor-approved conversion tooling where applicable and test business outputs before ordering a production configuration.

Validate data meaning and the final writes

Database migration acceptance checks
CheckWhat to reconcile
Schema and object coverageTables, procedures, jobs, users, permissions and external objects in scope.
Business data and behaviorBalances, transaction totals, dates, encodings and representative queries.
Final synchronization and write ownershipA controlled handover with the final transaction boundary recorded.
Restore and rollback after new writesA tested recovery method that accounts for destination-only transactions.

Plan the Power destination with Midland

Use the assessment to decide which workload belongs on Power before comparing hardware. Midland’s Power model catalog supplies the server identities; software eligibility and measured workload demand decide the configuration.

Prepare the conversion inventory and Bring your current OS, application and database versions to Midland.

Sources and release checks

Technical guidance checked October 21, 2026. Confirm the exact application edition, OS release and target architecture with its vendor before ordering. Older technical papers explain migration methods; they do not establish current certification.