SAP Migration

• Database migration (heterogeneous system copy), e.g. moving from a traditional database to HANA.
• S/4HANA conversion, which combines database migration with application conversion.
• Platform/cloud migration, moving the system to new infrastructure or the cloud.

Worth separating from these: a system copy is not a migration. It duplicates a system onto the same platform, which is how quality assurance is refreshed from production, and it is routine operational work rather than a project. The tooling overlaps, which is why the two get confused.

For moving to HANA, SAP’s Database Migration Option (DMO) of the Software Update Manager performs the database migration and (for conversions) the software update in one optimised, restartable procedure, minimising downtime and risk compared with separate steps.

The reason DMO exists is worth stating plainly. Moving to HANA and upgrading the application are two projects, and doing them separately means two downtime windows, two test cycles and an intermediate state nobody wants to run. DMO performs both inside one Software Update Manager run, so the system goes down once and comes up on the new database and the new release together.

Knowing the shape of a migration run tells you where the time goes and where it can fail.

Preparation runs while the system is still up: checks, the shadow repository build, and everything that does not need exclusive access. This phase is long and it costs no downtime.

Downtime begins. Users are locked out, and the tool takes over.

Export and import is the heart of it: tables are read from the source database and written to the target. This is the phase proportional to data volume, and it is where parallelism matters, because tables are moved by several processes at once and the largest table sets the floor for how fast it can finish.

Conversion applies the application changes on the new database.

Post-processing rebuilds what was set aside and the system comes back up.

The two levers on duration are parallelism, tuned by how many processes move tables, and volume, reduced by archiving and by dropping data nobody needs before you start. The second is the more effective and the one that has to happen weeks earlier.

Migrations move large volumes of data, so downtime minimisation (near-zero downtime options), data validation, and performance of the export/import are central concerns. Multiple rehearsal runs in non-production are standard to nail timing and catch issues.

The number the business needs is a rehearsed one. A first run produces an estimate and finds the problems; a second produces a plan. Table splitting and parallelism are tuned between runs, and the gain from that tuning is often substantial, which is precisely why one rehearsal is not enough.

Not something to run casually, and knowing what it should yield is useful whether or not you press the button.

1. A timed phase log, so you know which phase consumed the window and where tuning would help.
2. A list of the largest tables and how long each took, which is the input to table splitting for the next run.
3. An error list, nearly always data rather than technical: inconsistencies the old database tolerated and the new one will not.
4. A reconciliation: record counts per table before and after, checked rather than assumed.
5. A revised cutover plan with real timings, which is the actual deliverable.

Step three is where preparation time is genuinely saved. Every inconsistency found in a rehearsal is one not found at three in the morning during the real run.

After migration, validate data completeness and integrity, confirm the system starts and performs, and check integrations reconnect. Never treat the first migration attempt as the real one, rehearse.

Add to that list the things that are easy to forget: interfaces repointed to the right endpoints, background jobs rescheduled, printers and output devices working, transports importing, and a backup taken and tested on the new database before users are let in. A migrated system with no valid backup is one incident away from repeating the whole exercise. See restore for that side.

A database migration sounds like moving data and frequently carries conversions that are the real work.

Endianness and platform. Moving between processor architectures means the export and import must be platform independent, which is what the migration tooling handles and why a simple database backup and restore does not work across platforms.

Code page. Older systems ran non-Unicode, and moving to a current release requires Unicode conversion. That is a data conversion touching every character field, it can fail on data that was never valid in its declared code page, and it needs its own preparation and checks.

Data type changes. The target database may not support a type the source did in the same way, and the tooling maps them, occasionally with consequences for precision.

Table splitting. Very large tables are exported in parallel chunks, which is a tuning decision rather than a conversion and is the main lever on how long the export takes.

The consequence for planning is that a migration between platforms and code pages is a substantially larger exercise than one that is neither, and the first question is which conversions apply.

The words get used interchangeably and they describe different projects with different costs.

Migration moves a system to different infrastructure or a different database, keeping the release and the data. Nothing functional changes, and the risk is technical.

Conversion moves an existing system to a new release in place, keeping data, configuration and custom code, which then have to be remediated. The functional preparation dominates the effort.

New implementation builds a fresh system and migrates selected data into it. Configuration is designed rather than inherited, custom code is not carried across, and the effort is in design and data migration rather than remediation.

Selective data transition sits between the last two, taking chosen company codes or a period of history into a new build. It needs specialist tooling and it exists because the choice between keeping everything and keeping nothing is often wrong.

The question that decides it is how much of the existing system is worth keeping. A landscape with years of accumulated modifications nobody can justify is a case for starting again; one with clean configuration and a business that has not changed is a case for converting.

• No rehearsal runs before the real migration.
• Skipping data validation post-migration.
• Underestimating downtime, plan minimisation options.

• Archiving planned for after the migration. It is the single most effective way to shorten the window and it has to happen before.
• Tuning parallelism without measuring. More processes is not always faster, and the phase log says which.
• No rollback decision agreed in advance. See prerequisites, the Linux setup and software provisioning for the surrounding steps.

• Treating a migration and a conversion as the same project. One is technical and one is mostly functional preparation, and planning the second like the first is why conversions overrun.

Running the tool is the mechanical half, and planning a migration whose downtime window the business can actually accept is the part you do in the course.

The most effective thing you can do to shorten a migration window happens weeks before it: archive, and delete what nobody needs. Every document not moved is time not spent moving it, and no amount of parallelism competes with having less data.