OCI File Storage Migration to STACKIT File Storage

The migration in eight steps

The order follows the dependency waves of the demo run and adds the practice around them. Steps that use STACKIT facts name the limits that apply.

1. 01

   1. Inventory what exists

   List every file system, its mount target, its exports with their client ranges and access, and the instances that mount it. The demo estate has two file systems, one mount target and two exports. The run reads Terraform only, so mounts made by hand on clients are yours to find.

2. 02

   2. Prepare the STACKIT project

   SFS needs a project in a STACKIT Network Area with routing tables enabled. Its interconnection reserves a dedicated subnet and needs at least one /28 and four /29 subnets, and no new subnet may be smaller than /29.

3. 03

   3. Create the resource pool

   A pool is a container of fixed, reserved size between 500 GB and 20 TB, created in one availability zone; a zone such as eu01-m is a metro zone replicated to another. At creation you give it a size, an availability zone, a performance class and an IP ACL for the networks that may mount it; the pool itself mounts read-only.

4. 04

   4. Create the shares

   One share per OCI file system. A share has no fixed size and may use the whole pool, or you set a space limit. A pool holds up to 200 shares. The mount path is the pool address followed by the share name.

5. 05

   5. Turn exports into export policies

   Each OCI export option becomes a rule with an IP range, an order, and read_only or super_user flags. Without a policy a share inherits the pool ACL and mounts read-only only. The next section shows the demo exports.

6. 06

   6. Copy the data

   Use a file-level copy from a host that mounts both sides, for example rsync or rclone, with a first full pass while the source is live and a final pass after writes stop. Set the NFSv4 ID domain to stackit.cloud on clients, otherwise ownership can come out wrong.

7. 07

   7. Cut over the clients

   Mount with sudo mount -t nfs <address>:/<pool>/<share> <directory>, update fstab or your automation and restart the applications that held the old mount. The address changes, so anything with the OCI mount target address written in it changes too.

8. 08

   8. Verify, then retire

   Compare file counts and checksums on a sample, check permissions as the application user, then keep the OCI file system read-only for an agreed period. That is your rollback. Delete it only after that period.

The file system, assessed

A seven-resource Oracle Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: one file system of the input. Right: the decision recorded for it in assessment.json. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_file_storage_file_system" "media" {
  compartment_id      = var.compartment_id
  availability_domain = var.availability_domain
  display_name        = "media"
}

{
  "id": "oci_file_storage_file_system.media",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT File Storage (SFS)",
      "resources": [
        "stackit_sfs_resource_pool",
        "stackit_sfs_share",
        "stackit_sfs_export_policy"
      ]
    },
    "reason": "A file system becomes a STACKIT File Storage share. Data moves with a file copy, and mount targets and export rules are rewritten."
  }
}

• The file system has a target

  REPLATFORM at medium confidence, to STACKIT File Storage (SFS) as stackit_sfs_resource_pool, stackit_sfs_share and stackit_sfs_export_policy. The run lists SFS for both eu01 and eu02 in its STACKIT catalogue snapshot.

• Three settings named

  availability_domain, compartment_id and display_name are the settings the architect report lists for this unit. The availability domain has no direct form on STACKIT: you pick an availability zone for the pool.

• Data is listed, not moved

  migration/data-movement.md lists both file systems as stateful units with the mechanism UNKNOWN. StackToIT moves no data, and the size of the data is not in the Terraform.

The mount target and the exports, left to you

The same run for the two resources that control access. They are not in the engine catalogue, so nothing of them is assessed or drafted. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_file_storage_mount_target" "shared" {
  compartment_id      = var.compartment_id
  availability_domain = var.availability_domain
  subnet_id           = oci_core_subnet.files.id
  display_name        = "shared-mt"
}

resource "oci_file_storage_export" "media" {
  export_set_id  = oci_file_storage_mount_target.shared.export_set_id
  file_system_id = oci_file_storage_file_system.media.id
  path           = "/media"

  export_options {
    source          = "10.40.0.0/16"
    access          = "READ_WRITE"
    identity_squash = "NONE"
  }
}

[
  {
    "id": "oci_file_storage_mount_target.shared",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_file_storage_mount_target is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_file_storage_export.media",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_file_storage_export is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• MANUAL_REVIEW at low confidence

  Both types come back as unknown source types. The report names them in its section of unknown source types and adds a warning to the file systems and the subnet linked to them: the effect of the linked resource on the migration is not assessed.

• The exports hold the access rules

  The media export allows 10.40.0.0/16 with READ_WRITE and identity squash NONE; the home export allows 10.40.3.0/24 with READ_ONLY and identity squash ROOT. These are the rules to rebuild: two policies with one rule each, or one policy per client group.

• Order of the move

  Waves from the dependencies: the VCN and both file systems in wave 1, the subnet in wave 2, the mount target in wave 3 and the two exports in wave 4. On STACKIT, the pool and shares come first and the export policies are attached to the shares.

How the estate maps

Classes as the run decided them. The right-hand column for the mount target and the exports is a design reading, not a run result: the run states no target for them.

What differs between the two services

A pool snapshot covers every share in the pool. If two applications must be restorable independently, give them separate pools.

Decisions your architects own

• Pools and shares

  One pool per application group or one large pool. Capacity is reserved per pool and snapshots are per pool, so the grouping decides cost and restore scope.

• Performance class

  Each pool has one class. The run's STACKIT catalogue snapshot lists three SFS performance classes in eu01 and in eu02; pick one from the throughput your workload shows today.

• Export policy design

  Which client ranges mount read-write, which read-only and which need root. Keep the rule order deliberate, because the first match wins.

• Copy method and window

  A live first pass plus a short final pass keeps downtime small. A single pass after stopping writes is simpler for small shares.

• Snapshot schedule

  OCI snapshots do not travel with a file copy. Set a pool snapshot schedule and an immutable period on STACKIT if you need one.

• Client changes

  ID domain, mount address and mount options on every client. Collect them in your configuration management before the cutover day.

Questions storage teams ask

Sources

• OCI File Storage overview
• STACKIT File Storage: resources
• STACKIT File Storage: limits
• STACKIT File Storage: mounting resource pools and shares
• STACKIT File Storage: concepts and terminology
• stackit_sfs_export_policy resource, STACKIT provider 0.121.0