The build phase can start after the assessment of the current environment is complete, and the proof of concept succeeds in achieving the goals originally documented and approved. Building the new landscape will utilize the insights gathered during the previous phases, but have different desired outcomes. The new pipeline should integrate with existing tools, support architecture, process controls, and any other dependencies already identified.

You should deploy the new build side-by-side to the current environment, so it remains entirely sandboxed from the production systems. While singular capabilities were part of the assessment and proof of concept stages, you’ll now want to test the technologies for items such as ease of management, overall scalability, or added automation capabilities.

Once the environment is available, connect legacy data and deploy company-specific configurations. Although running the new environment concurrently with the legacy system will create duplicate processing, it’s necessary to burn-in the new technology stack adequately. There should also be contingencies put in place that enables you to roll back in the event that any failures occur. You can now direct more and more traffic to the new DevOps solution, ensuring its capabilities and that you’ve met or exceeded all the project’s requirements.

Once the build is stable and operating as designed, use the migration project’s lessons learned and tool experts to develop best practices and establish a knowledge base. Finally, you can communicate with the entire organization about the project’s success and plan the launch.