Migration environments

You migrate configuration content from one environment to another.

Development and testing typically occurs in a preproduction environment. You typically migrate configuration content between the following environments:

Development environment
After you identify the configuration changes that you want to make to your product, you can implement them in a development environment. In the development environment, you can perform basic tests to the changes. A development environment is useful if code must be written, compiled, and deployed into a product to accompany changes to configuration applications. In the migration process, in most situations, the development environment is only a source environment.
Test environment
You perform thorough testing of the configuration changes in the test environment. You can use a single test environment to mimic the production environment. For the most accurate testing, the test environment must contain all the business applications and configuration changes that you intend to use in the production environment. A single test environment is best suited to aggregating changes that you create in separate development environments. In the migration process, the test environment can be both a source and target environment.
Production environment
After thorough testing, when the changes meet all the requirements, you are ready to migrate your changes to the production environment. When moving configuration content to production, schedule the promotion to occur during maintenance periods. The deployment of Migration Manager packages must be treated in the same manner as product installations and fix packs. In some situations, the deployment of packages might require your application server to remain unavailable to your users for some time. In the migration process, in most situations, the production environment is only a target environment.

You identify source and target environments by using unique identifiers. The identifier is the combination of the database host name, the database identifier, and the database schema name.

A target environment can be used with any package definition. You can set inbound restrictions in a target environment to prevent the distribution and deployment of packages to that environment from restricted sources.



Feedback