Understand how the mta-ops CLI connects to your environments to ensure your migration commands route to the correct destinations.

The mta-ops command-line interface (CLI) operates entirely locally. It does not require a centralized web console or an intermediate authentication hub. The tool uses your local kubeconfig file to authenticate and communicate directly with clusters.

Because the pipeline extracts data from one environment and validates against another environment, your kubeconfig file must contain active contexts for both clusters simultaneously. mta-ops uses the --context flag to route operations. This design securely uses your existing role-based access control (RBAC) permissions without requiring secondary credentials.

To enable the mta-ops CLI to communicate with your environments, configure your local cluster contexts. You perform this by logging into both the source and target clusters.

When you extract workloads, understanding the read-only export process helps you to capture the required resource manifests.

The export process is read-only and does not affect running applications. The mta-ops CLI operates completely independently of the migration toolkit for applications Hub.

The tool does not require a Personal Access Token (PAT). It authenticates directly to the clusters by using your local kubeconfig file.

If you do not have cluster-level permissions, the command logs a warning. It records inaccessible resources in a dedicated failures/ directory.

To identify skipped cluster-scoped resources during a partial export, you must inspect the failures/ directory. The tool generates a YAML artifact for each inaccessible resource. These files contain the raw application programming interface (API) error.

The export command exits with a non-zero status code only if all requested resource types return a Forbidden error.

To capture your application’s deployment configuration, export the manifests to a local directory. You can use role impersonation if you do not have direct access.

When you adapt complex applications, you can manage transformation plugins to control the pipeline. This ensures the tool cleans specific metadata and applies additional transformations, if needed.

The mta-ops command-line interface (CLI) automatically discovers plugins from the ~/.local/share/crane/plugins/ default path. You can view available plugins by using the list-plugins subcommand.

During the transform stage, you can use the --skip-plugins flag to omit specific plugins. You can use the --optional-flags parameter to pass additional arguments.

To drive the transformation behavior by using specific user-defined rules, you can append the --instructions-file flag. This supplies a declarative YAML file to the pipeline.

Understand how the multi-stage transformation pipeline produces Kustomize-native output. This allows you to accurately trace modifications.

The mta-ops transform command processes exported manifests through sequential plugin stages. The pipeline produces a standard Kustomize layout.

transform/
├── 10_KubernetesPlugin/
│   ├── input/
│   ├── output/
│   ├── patches/
│   └── kustomization.yaml
├── 15_OpenShiftPlugin/
│   ├── input/
│   ├── output/
│   ├── patches/
│   └── kustomization.yaml
└── 50_CustomModifications/
    ├── input/
    ├── output/
    ├── patches/
    └── kustomization.yaml

The directory structure uses the following components:

Plugin stages safely regenerate upon execution. However, custom stages require manual forced overwrites to protect your edits.

Transform your exported manifests to remove cluster-specific metadata. This prevents conflicts on the target Red Hat OpenShift cluster.

When you need specific rules during the cleanup process, use an instructions file. This declarative file controls the pipeline execution.

To adapt migrated resources to new environment standards, add a custom transformation stage. You can layer declarative patches directly on your application.

Understand how the mta-ops apply command renders your transformed manifests locally. This ensures your final YAML is ready for deployment.

The mta-ops apply command runs Kustomize on the final transform stage. It evaluates patches internally by using the embedded krusty application programming interface (API). This embedded rendering removes the runtime dependency on the kubectl or oc binaries.

The command produces clean, deployable manifests on your local disk. It does not deploy resources to any cluster. The output includes individual resource files and a consolidated output.yaml file.

The mta-ops tool orders resources in the consolidated file to satisfy cluster dependencies. For example, it places custom resource definitions (CRDs) before namespace-scoped resources. You can exclude cluster-scoped resources by appending the --skip-cluster-scoped flag. This supports split-responsibility workflows between administrators and non-administrators.

To produce clean YAML files, generate your final manifests. You use the mta-ops apply command to render the Kustomize output locally.

When you render your final YAML, you can generate ordered individual resource files. This ensures you apply resources in the correct dependency order.

Validation is a read-only optional check for your final workload manifests before their deployment on a target cluster. It prevents deployment failures by identifying API incompatibilities.

You can use the mta-ops validate command to evaluate your generated manifests against the target Red Hat OpenShift cluster’s application programming interface (API) surface. The command performs strict group, version, and kind (GVK) matching. The tool reads the API discovery information without modifying the cluster.

The validation command generates a report identifying incompatible resources. It saves the detailed results to a specified validation directory. If incompatibilities are found, the tool logs the failing artifacts in a failures/ subdirectory.

The validation process supports the following modes:

To verify application programming interface (API) compatibility before deployment, validate your transformed manifests against a live target Red Hat OpenShift cluster.

Understand the final step of the stateless workload migration pipeline and deploy the validated manifests to the target cluster.

The mta-ops pipeline produces ready-to-use YAML artifacts on your local disk. It deliberately does not connect to the target cluster. This non-destructive architecture ensures that the target cluster remains untouched until manual deployment.

Because the pipeline outputs standard Kubernetes manifests, it is fully GitOps-ready. You can commit the final YAML to a repository.

Applying the consolidated output.yaml file resolves dependency ordering issues during deployment. Applying the entire directory can cause deployment failures if roles execute before role bindings.

To finalize your migration, deploy the validated workloads by applying the generated manifests to the target Red Hat OpenShift cluster.

When you lack cluster-admin privileges, deploy your workloads as a non-administrator. This allows you to apply namespace-scoped resources safely.