Migration Toolkit for Applications 8.3 joins code modernization to storage mobility

Red Hat has made Migration Toolkit for Applications 8.3 generally available, broadening the product from code and manifest modernization into container and data migration. The release is also the official transition path as Migration Toolkit for Containers reaches end of support.

The practical change is that an application migration can now cover more of the workload boundary: cluster objects, persistent data, build definitions, delivery pipelines and—in developer preview—multi-agent code transformation.

What changed for cluster and storage migrations

MTA 8.3 adds Kustomize-based manifest handling and automation for cluster dependencies including custom resource definitions and security context constraints. A read-only preflight tool checks API compatibility against the destination cluster before a migration proceeds.

For stateful workloads, the release introduces three storage paths. Direct PVC transfers use TLS-encrypted tunnels and a stage-and-cutover sequence, moving most data while an application remains online before a shorter delta transfer. Indirect migration uses S3 for disconnected or cross-cloud movement, with client-side encryption and credentials held in Kubernetes Secrets; Red Hat says that path is validated for AWS S3. An intra-cluster conversion flow clones data into a newly provisioned PVC and rebinds workloads to move between storage classes without editing the application manifests.

The release also includes a technology-preview transformation from legacy OpenShift BuildConfig resources to OpenShift Build custom resources.

The agentic migration factory

The most ambitious addition is explicitly a Developer Preview, not a generally available capability. The agentic migration factory runs configurable multi-agent workflows on OpenShift. Red Hat positions it for migrations such as moving JBoss EAP 6 applications toward Quarkus: separate agents can analyze dependencies, remediate code, validate builds and create deployment configuration.

Each stage exchanges context through a handoff file on a shared Git branch. Red Hat says the agents run in sandboxes with policy, RBAC and audit boundaries, while credentials remain isolated from the agent processes. The initial implementation uses the Agent Sandbox project; Red Hat plans to move later iterations to OpenShell.

That maturity boundary matters. Teams can evaluate the workflow engine, but should not treat its presence in an 8.3 GA product release as making the agentic factory itself production-supported.

A generated delivery baseline

MTA 8.3 also ships three Helm-based generators. The OpenShift Pipelines generator creates a Tekton flow for source retrieval, container builds and configuration-repository updates. The OpenShift GitOps generator creates an Argo CD Application with automated synchronization, pruning and self-healing. The Java Service generator produces Kubernetes manifests and a multi-stage Containerfile for Spring Boot and Quarkus JVM applications.

Platform teams can associate those generators with archetypes in the MTA Hub, giving application portfolios a repeatable destination pattern rather than leaving every migrated service to assemble a delivery stack independently.

For teams planning a move from Migration Toolkit for Containers, the immediate work is to test MTA 8.3’s preflight and PVC paths against their cluster, network and storage constraints. Red Hat points operators to the mta-ops CLI for PVC migration and to the product documentation for the preview agent workflow.