Migrating databases hosted on VMware VMs to STACKIT

The VMs the run hands back

Left: the disks of ora19c-01, one node of an Oracle pair with a shared disk, and of rdm-san01, a VM with a raw device mapping, from the vDisk sheet. Right: the part of terraform/README.md that lists what the run left for the architect.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
ora19c-01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-01] ora19c-01/ora19c-01_0.vmdk,4202-vm16-0004
ora19c-01,Hard disk 2,512000,False,independent_persistent,sharingMultiWriter,False,SCSI controller 1,virtualSharing,[ds-db-01] ora19c-01/ora19c-01_1.vmdk,4202-vm16-0004
rdm-san01,Hard disk 1,61440,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-02] rdm-san01/rdm-san01_0.vmdk,4202-vm16-0007
rdm-san01,Hard disk 2,2097152,True,independent_persistent,sharingNone,False,SCSI controller 1,noSharing,[ds-db-02] rdm-san01/rdm-san01_1.vmdk,4202-vm16-0007

| Source | Class | Why |
|---|---|---|
| `vm.ora19c-01` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.ora19c-02` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.rdm-san01` | MANUAL_REVIEW / MEDIUM | Raw device mapping: the LUN is not part of the VM image, so an image export does not carry its data; it needs a block- or application-level copy to a STACKIT volume. |

• Shared disk, no automatic draft

  Both Oracle nodes have a disk in multi-writer sharing mode on a shared bus. The run classifies them MANUAL_REVIEW and writes no server for them. A STACKIT data volume attaches to one server at a time, so a shared-disk cluster needs a new design, not a copy.

• Raw mapping, data outside the image

  The Raw column is True for the second disk of rdm-san01. The run states that the LUN is not part of the VM image, so an export does not carry its data and a block- or application-level copy is needed.

• Three of nine units

  Nine units were assessed, two networks and seven VMs. Six were drafted as Terraform and three are left for a person.

A PostgreSQL primary, rehosted

Left: the three disks of pg-prod01. Right: the server and the two data volumes of the draft, without the review comments above each block.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
pg-prod01,Hard disk 1,81920,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-01] pg-prod01/pg-prod01_0.vmdk,4202-vm16-0001
pg-prod01,Hard disk 2,1048576,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[ds-db-01] pg-prod01/pg-prod01_1.vmdk,4202-vm16-0001
pg-prod01,Hard disk 3,204800,False,persistent,sharingNone,False,SCSI controller 2,noSharing,[ds-db-01] pg-prod01/pg-prod01_2.vmdk,4202-vm16-0001

resource "stackit_server" "vm_pg_prod01" {
  project_id        = var.project_id
  name              = "pg-prod01"
  machine_type      = var.vm_pg_prod01_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type = "image"
    source_id   = var.vm_pg_prod01_image_id
    size        = 80
  }
  network_interfaces = [stackit_network_interface.vm_pg_prod01_nic1.network_interface_id]
}

resource "stackit_volume" "vm_pg_prod01_disk2" {
  project_id        = var.project_id
  name              = "pg-prod01-disk2"
  availability_zone = var.availability_zone
  size              = 1024
  performance_class = var.vmware_volume_performance_class
}

resource "stackit_server_volume_attach" "vm_pg_prod01_disk2" {
  project_id = var.project_id
  server_id  = stackit_server.vm_pg_prod01.server_id
  volume_id  = stackit_volume.vm_pg_prod01_disk2.volume_id
}

resource "stackit_volume" "vm_pg_prod01_disk3" {
  project_id        = var.project_id
  name              = "pg-prod01-disk3"
  availability_zone = var.availability_zone
  size              = 200
  performance_class = var.vmware_volume_performance_class
}

resource "stackit_server_volume_attach" "vm_pg_prod01_disk3" {
  project_id = var.project_id
  server_id  = stackit_server.vm_pg_prod01.server_id
  volume_id  = stackit_volume.vm_pg_prod01_disk3.volume_id
}

• Disks keep their roles

  The 80 GiB system disk becomes the boot volume, the 1 TiB data disk a volume of 1024 GiB, the 200 GiB disk (the write-ahead log in this estate) a volume of 200 GiB. The names are the draft's; the roles are your knowledge of the database.

• Data is copied later

  Each volume block notes that the data is copied after creation. The run never moves data.

• Within the volume limits

  The block storage documentation gives data volumes a range of 1 GB to 16 TB each, so a 1 TiB volume fits.

Telling the run how much downtime an application allows

Left: an applications file written for this estate. It names the units of two applications and states RTO, RPO and downtime tolerance as the owners gave them. Right: the rows of migration/waves.csv that show the result. The file is passed with the --applications flag.

applications:
  - id: orders-db
    name: Orders database
    selectors:
      - vm.pg-prod01
      - vm.pg-prod02
    environment: production
    owners:
      business: sales
      technical: dba-team
    business_criticality: critical
    availability:
      rto: 2h
      rpo: 5m
      downtime_tolerance: 30m
  - id: wiki
    name: Team wiki
    selectors:
      - vm.mysql01
    environment: production
    business_criticality: low
    availability:
      downtime_tolerance: 8h

wave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
2,MEMBER,vm.mysql01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,wiki,CONFIRMED,
2,MEMBER,vm.ora19c-01,vmware_vm,,KNOWN_PRESENT,MANUAL_REVIEW,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,vm.pg-prod01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,orders-db,CONFIRMED,
2,MEMBER,vm.pg-prod02,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,orders-db,CONFIRMED,

• Only what you name is assigned

  pg-prod01 and pg-prod02 belong to orders-db, mysql01 to wiki. ora19c-01 stays UNASSIGNED because no selector names it.

• Values are recorded as written

  RTO of 2h, RPO of 5m and downtime tolerance of 30m appear in migration/applications.csv exactly as given. Data classification stays NOT_PROVIDED where the file says nothing.

• The run does not calculate

  No transfer time or cutover window is derived from these values. They frame the decision you take below.

What the run says about data movement

From migration/data-movement.md of the same run, two lines that matter for every database that lives inside a VM.

StackToIT never moves data. The source holds no database, cache, search domain, warehouse, volume, file share or object store, but it holds servers or virtual machines. Data that lives on the disks of a server or virtual machine is not looked at, so whether data has to move is not assessed.

State: NOT ASSESSED.

• Not assessed, by design

  A database on a VM disk is just a disk to the run. It lists no database, no size and no mechanism for it.

• You choose the mechanism

  Size, change rate, downtime tolerated and the consistency the application needs decide between a disk copy, a dump and restore, a backup import or replication.

Where each database can land

Statements about STACKIT services come from the documentation pages listed under the sources and may change; check the current pages. StackToIT itself drafts only the rehost path for these VMs.

The migration in order

1. 01

   Find the databases yourself

   The export has VMs, not engines. Use the Annotation column, your CMDB and the DBAs: the run does not detect database software from names or notes.

2. 02

   Pick a target per database

   Rehost keeps engine and version and leaves patching, backup and high availability with you. A managed service takes that work over but needs a supported version and a data move.

3. 03

   Record downtime and recovery values

   Put RTO, RPO and downtime tolerance into an applications file so they travel with the plan, and run the assessment again.

4. 04

   Build the target

   For rehost, fill the variables of the draft: machine type, image ID, volume performance class, network prefixes. For a managed service, create the instance yourself; the draft writes none.

5. 05

   Seed the data

   Examples of general practice: a dump and restore for PostgreSQL, a backup import for SQL Server, or replication to keep the target current until cutover. Rehearse with a copy and time it.

6. 06

   Verify, then cut over

   As general practice, compare row counts and run application checks on the target, switch the connection strings or DNS names, and keep the source VM stopped but intact until the owner signs off. This is general practice, not a run output.

7. 07

   Keep the way back

   Until sign-off the source remains the system of record. Write down how to point applications back to it.

Decisions the architect owns

• Rehost or managed

  Per database, not per estate. A managed service removes work and adds constraints on version, extensions and access.

• Version

  Moving to a managed service often means a supported version. As of November 2026, the lifecycle page gives November 2026 as the end of life of PostgreSQL 14 and November 2025 for 13, so do not choose either for a new target; 16 or 17 leave the most time.

• High availability

  Two VMs with streaming replication, as in this estate, and a three-node replica set are different designs. Decide which you want and test failover.

• Downtime

  The applications file records what each owner can accept. Choose a seeding method that fits, replication for tight windows, dump and restore where hours are acceptable.

• Storage class

  The volume performance class is one variable for the estate in the draft. Databases with a log disk may need a different class than file servers.

• Cluster design

  Shared-disk clusters and raw mappings are the VMs the run hands back. They need a design decision before any copy.

Questions database teams ask

Sources

• STACKIT documentation: PostgreSQL Flex architecture
• STACKIT documentation: PostgreSQL Flex version lifecycle
• STACKIT documentation: import a SQL Server backup into SQLServer Flex
• STACKIT documentation: transactional replication into STACKIT
• STACKIT documentation: block storage concepts
• STACKIT documentation: MariaDB introduction