Migration toolkit for applications 8.2: Modernize your applications and clusters

You can now modernize your applications and migrate your clusters with less infrastructure overhead and more control. Red Hat's migration toolkit for applications 8.2 is now available.
This release focuses on giving platform engineers, developers, and cluster administrators more control, less infrastructure overhead, and a security-focused, GitOps-ready workflow. Migration toolkit for applications 8.2 introduces a brand-new standalone migration CLI (mta-ops
) for stateless OpenShift workloads and replaces mandatory external identity management footprints with a sleek, built-in Hub OpenID Connect (OIDC) provider.
The new mta-ops CLI: Safe, stateless OpenShift migrations
Moving workloads across environments can be a nerve-wracking process. To solve this, migration toolkit for applications 8.2 introduces the mta-ops
CLI, a standalone, non-destructive tool to migrate stateless applications across Red Hat OpenShift 4.x clusters.
Operating entirely on your local workstation via your existing kubeconfig
contexts, mta-ops
doesn't alter your source or target clusters automatically. Instead, it guides your manifests through a strict, deterministic, five-stage pipeline:
Export → Transform → Apply → Validate → Deploy
Core highlights of the mta-ops
pipeline:
- Zero cluster alterations: The tool extracts data locally and saves all intermediate steps to your disk.
- Kustomize-native multi-stage transformations: The transform stage organizes modifications into isolated, numbered directories (for example,
10_KubernetesPlugin
,15_OpenShiftPlugin
). You can layer custom, declarative patches using your ownkustomization.yaml
files or rule-based instructions. - Embedded local rendering: The apply stage uses an embedded
krusty
API engine to render final manifests. This removes any hard runtime dependencies onkubectl
oroc
binaries during composition. - Strict API validation: Before deploying,
mta-ops validate
runs strict Group, Version, and Kind (GVK) matching against your target cluster (either in live mode or offline mode via a captured API surface JSON file)—saving you from catastrophic runtime deployment failures due to deprecated APIs.
mta-ops
currently focuses strictly on stateless migrations, including namespace resources and cluster-scoped dependencies like role-based access control (RBAC), custom resource definitions (CRDs), and security context constraints (SCCs). Stateful migrations involving persistent volume claims (PVCs) are planned for future releases.
A built-in Hub OIDC provider
Historically, managing users, roles, and permissions in Red Hat's migration toolkit for applications meant provisioning and maintaining an external Red Hat build of Keycloak instance—along with its mandatory 1 GiB database volume.
Migration toolkit for applications 8.2 changes this architecture by embedding a standards-compliant Hub OIDC provider directly into the application.
Why this matters for infrastructure and administration
- Reduced footprint: If you are installing the migration toolkit for applications for the first time or don't have a pre-existing Red Hat build of Keycloak deployment in your namespace, the migration toolkit for applications will no longer force the deployment of a Keycloak operator or an underlying Postgres database.
- Flexible authentication paths: You can choose the authentication style that best fits your enterprise:
- Local authentication: Create users and manage fine-grained, custom roles directly inside the migration toolkit for applications web console.
- LDAP and Active Directory integration: Federate authentication out to your corporate directory server using the new
LdapProvider
custom resource (CR), complete with wildcard pattern matching and flexible AND/OR logic mapping. - External provider connection: Use the MTA Hub as an OIDC broker to connect with external providers like Google, Okta, or Microsoft Entra ID via the
IdentityProvider
CR.
Enterprise token management and automation-ready security
For teams looking to embed Red Hat's migration toolkit for applications inside their automated CI/CD pipelines, security and token lifespans are paramount. Migration toolkit for applications 8.2 upgrades its token management lifecycle to accommodate modern developer operations:
- Short-lived access tokens: Built on short-lived JSON Web Tokens (JWTs signed via RSA) that default to a five-minute lifespan to minimize the radius of token exposure.
- Long-lived personal access tokens (PATs): Need to connect an external automation script? You can now generate API keys directly from the web console with custom lifetimes up to a maximum ceiling of 10 years (configured via
hub_apikey_lifespan
in yourTackle
CR). - Instant revocation safeguards: When an administrator or user revokes an API key, the Hub invalidates it instantly. A secondary safety-net cache refresh helps maintain an absolute worst-case staleness window of just five minutes.
Modernized developer workflows: Integrated IDE authentication
Modernization doesn't only happen in the terminal. Red Hat updated the migration toolkit for applications 8.2 IDE extension to fully support this new lightweight OIDC architecture.
Developers can now trigger OIDC device authentication directly from the IDE Command Palette (MTA: Konveyor Analysis View). The extension safely authenticates against the Hub URL, enabling profile sync (to pull down centralized analysis profiles), access to the solution server for automated code suggestions, and LLM proxy support—all without forcing manual re-authentication before token expiration.
Ready to start your production migration?
If you're planning a Java migration to cloud-native platforms, Red Hat provides enterprise-grade tools complementing this approach.
Migration toolkit for applications
Red Hat's migration toolkit for applications:
- Analyzes Java Enterprise Edition (Java EE), Spring Boot, and legacy applications.
- Identifies migration issues, effort estimation, and transformation patterns.
- Generates detailed reports with line-by-line code recommendations.
- Supports Java EE to Jakarta Enterprise Edition (Jakarta EE), Spring Boot to Quarkus, and WebLogic or WebSphere to Red Hat JBoss Enterprise Application Platform (JBoss EAP).
Red Hat OpenShift
- Production Kubernetes platform with enterprise support.
- Integrated CI/CD, monitoring, security-focused features, and compliance management.
- Developer tools: Source-to-Image (S2I), Red Hat OpenShift Dev Spaces, and Red Hat OpenShift Serverless.
- Runs anywhere: on premise, Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and IBM Cloud.

Facts Only

* Red Hat's migration toolkit for applications 8.2 is available.
* It includes a standalone migration CLI named mta-ops for stateless OpenShift workloads.
* mta-ops operates locally using existing kubeconfig contexts and does not automatically alter source or target clusters.
* The migration process follows a five-stage pipeline: Export, Transform, Apply, Validate, Deploy.
* The transform stage uses Kustomize-native multi-stage transformations organized into numbered directories.
* The apply stage uses an embedded krusty API engine for local rendering of manifests.
* mta-ops performs strict API validation using Group, Version, and Kind matching before deployment.
* The tool currently focuses on stateless migrations, including namespace resources, RBAC, CRDs, and SCCs; stateful migrations are planned for future releases.
* A built-in Hub OIDC provider replaces mandatory external Keycloak footprints.
* Token management includes short-lived JWTs (default five-minute lifespan) and customizable long-lived Personal Access Tokens (PATs).
* IDE extension supports OIDC device authentication directly from the IDE Command Palette.

Executive Summary

Red Hat's migration toolkit for applications 8.2 introduces a new CLI, mta-ops, designed to facilitate stateless application migrations across Red Hat OpenShift 4.x clusters with reduced infrastructure overhead and enhanced control. The mta-ops tool guides users through a five-stage pipeline: Export, Transform, Apply, Validate, and Deploy, operating locally on the workstation using existing kubeconfig contexts. This process ensures zero cluster alterations by keeping intermediate steps local to the user. A significant architectural change involves embedding a Hub OpenID Connect (OIDC) provider directly into the toolkit, eliminating the historical requirement for external Keycloak deployments. This new provider supports various authentication paths, including local, LDAP/Active Directory integration via custom resources, and connection to external providers like Google or Okta. Furthermore, security is enhanced through short-lived JWT access tokens and flexible long-lived personal access tokens with instant revocation safeguards. The update also modernizes developer workflows by integrating IDE authentication via the OIDC architecture.

Full Take

The introduction of mta-ops shifts application migration from a potentially high-risk, environment-altering procedure to a controlled, deterministic local workflow, emphasizing safety through strict validation and local state management. The shift away from mandatory external identity management to an embedded Hub OIDC provider represents a significant architectural trend towards self-contained, federated infrastructure components, reducing operational complexity and the attack surface associated with managing separate identity services like Keycloak. The layered approach in the transformation stage, allowing for custom Kustomize layering, demonstrates a pattern of empowering platform engineers to define complex state changes declaratively while maintaining systemic integrity through API validation—a necessary counterbalance to the velocity of modern DevOps. However, embedding security concerns into application tooling requires careful scrutiny regarding token lifecycles and access control structures; the promise of reduced footprint must be balanced against the inherent risk of tightly coupling sensitive identity operations within a migration tool. The design invites questioning about where the responsibility for external provider synchronization lies when using flexible authentication paths like LDAP or OIDC brokering, and what safeguards exist against drift between local configuration and centralized enterprise policies.

Sentinel — Human

Confidence

This text reads like an official product announcement or highly polished technical summary, strongly suggesting human authorship based on deep domain expertise.

Signals Detected

Moderate sentence length variance; uses specialized technical jargon fluently.

High internal logical flow connecting new features (mta-ops, OIDC) to administrative implications (footprint reduction).

Follows a structured announcement format; uses specific product names and feature lists suggesting direct source material.

Claims are highly specific technical details (e.g., five-minute token lifespan, Kustomize structure) which suggest fidelity to internal documentation or precise reporting.

Human Indicators

The text maintains a high density of deeply embedded, context-specific technical details that typically originate from official product release documentation or very specialized industry reporting.