The artifact files generated during the migration include the following:
deployment_spec.yaml: The YAML file that configures your workload.
You can use kubectl apply with this file to deploy the workload to another
cluster, such as a production or test cluster.
Dockerfile: The Dockerfile used to build the image for your migrated
VM.
Some plugins might generate more than one Dockerfile and deployment_spec.yaml
file, for example if you have a VM running multiple Tomcat servers at the
same time.
Additionally, when you run the migration to a Linux system container,
Migrate to Containers CLI also generates the following files:
migration.yaml: A copy of the migration plan. You can use this file
to verify what was done as part of the migration.
blocklist.yaml: The list of container services to disable based on your
settings in the migration plan. Edit this file to control the list of
services. For more information, see
Customize the services list.
logs.yaml: A list of log files detected on the source VM. Data written
to these log files by the migrated workload is forwarded to
Cloud Logging.
Edit this file to control log writing.
For more information, see
Customize log data written to Cloud Logging.
The deployment_spec.yaml file
This file is a YAML file that you can use to deploy your workload to
another cluster, such as a test or production cluster.
If you don't configure a data migration, you will generate a Deployment
object.
When the data migration is configured, you generate a stateful set object.
Dockerfile
Use this file if you need to generate a new version of the image.
For example, you might want to install a package and capture a new image
afterward. Rebuilding the image can also be useful when the
Migrate to Containers CLI is upgraded, for example to implement a bug fix,
and you want to rebuild the image with the
new Migrate to Containers CLI runtime. The upgraded runtime is available in
the Container Registry.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Review the migration artifacts\n==============================\n\nThis page describes the migration artifacts that the Migrate to Containers CLI\ngenerates as part of your migration.\n\nBefore you begin\n----------------\n\n- You should have first [created a migration plan](/migrate/containers/docs/m2c-cli/create-a-migration-plan) and [executed the migration](/migrate/containers/docs/m2c-cli/execute-the-migration-plan).\n\nAbout the generated artifact files\n----------------------------------\n\nThe artifact files generated during the migration include the following:\n\n- `deployment_spec.yaml`: The YAML file that configures your workload.\n You can use `kubectl apply` with this file to deploy the workload to another\n cluster, such as a production or test cluster.\n\n- Dockerfile: The Dockerfile used to build the image for your migrated\n VM.\n\nSome plugins might generate more than one Dockerfile and `deployment_spec.yaml`\nfile, for example if you have a VM running multiple Tomcat servers at the\nsame time.\n\nAdditionally, when you run the migration to a Linux system container,\nMigrate to Containers CLI also generates the following files:\n\n- `migration.yaml`: A copy of the migration plan. You can use this file\n to verify what was done as part of the migration.\n\n- `blocklist.yaml`: The list of container services to disable based on your\n settings in the migration plan. Edit this file to control the list of\n services. For more information, see\n [Customize the services list](/migrate/containers/docs/m2c-cli/linux/customizing-a-migration-plan#customize_the_services_list).\n\n- `logs.yaml`: A list of log files detected on the source VM. Data written\n to these log files by the migrated workload is forwarded to\n [Cloud Logging](/logging/docs/overview).\n Edit this file to control log writing.\n For more information, see\n [Customize log data written to Cloud Logging](/migrate/containers/docs/m2c-cli/linux/customizing-a-migration-plan#log-files).\n\n### The `deployment_spec.yaml` file\n\nThis file is a YAML file that you can use to deploy your workload to\nanother cluster, such as a test or production cluster.\nIf you don't configure a data migration, you will generate a `Deployment`\nobject.\nWhen the data migration is configured, you generate a stateful set object.\n\n### Dockerfile\n\nUse this file if you need to generate a new version of the image.\nFor example, you might want to install a package and capture a new image\nafterward. Rebuilding the image can also be useful when the\nMigrate to Containers CLI is upgraded, for example to implement a bug fix,\nand you want to rebuild the image with the\nnew Migrate to Containers CLI runtime. The upgraded runtime is available in\nthe Container Registry.\n\nYou can edit this file like any other Dockerfile to customize your image.\nFor tips, see\n[Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).\nFor information on how to edit the Dockerfile, see\n[Post-migration image updates](/migrate/containers/docs/post-migration-image-updates).\n\nWhat's next\n-----------\n\n- Learn how to [migrate data](/migrate/containers/docs/m2c-cli/migrate-data)."]]
