Cloud Migration in 5 Steps

In Part 1 of this article, we started down the path to successfully tackling your cloud migration project:


Now we move on to strategy, implementation, and the steps you can take to extend cloud efficiencies through your operations.


Step 3: Develop the Strategy


This step involves:

  • sharing the primary goal

  • forming a team to support it

  • identifying metrics around targeted results


Once you have a solid idea of your primary goal, communicate it, starting at the top. If you’re this far along the path, you know by now the business case for cloud migration makes itself. If you’re able to obtain an executive mandate—great. If not, you can still make the move a top priority by taking a leadership role. Dynamic leadership is consistently linked to successful cloud migrations.


With that in mind, share the goal with key stakeholders in the media supply chain. Emphasize how migrating to a cloud-native infrastructure will eliminate manual tasks and free up resources for more critical objectives. Identify the area of impact on the workload and on the operation at large. Prepare the affected community. If your migration entry point is No. 1 content receipt, for example, give suppliers plenty of time to accommodate a new platform in case their own business decisions are affected. Discovery did this with a roadshow for all their top content suppliers to let them know things were going to change and how to prepare.


On your own turf, seek the input of those directly affected. Establish that the goal is non-negotiable, but the migration strategy is adaptive. Talk to producers, QC techs and support operators. Get their feedback. Prepare for resistance—resistance to organizational change is a field of study all its own. Reasons range from the unknown impact on job security to a loss of expertise to just finding the time to learn new skills while doing the job at hand. One factor consistently mentioned in the field of change resistance is the one most easily addressed: communication.


“When you decide to make widespread changes, proper communication about why you’re making the changes and how you plan to implement them is essential,” writes Sampson Quain in the Houston Chronicle. “If your employees have no idea why you’re asking them to change protocols that they’re familiar and comfortable with, they tend to resist those changes.”


Encourage people to share doubts and ask questions, so misconceptions can be curtailed early on. Have them look for the gaps in your plan and help refine it. Let them know how the move will affect the workload distribution and skill-set demands.


Begin team-building. Identify those within the organization who are on board and enlist their support. Empower them to address misconceptions. Consider forming a steering committee. Designate a representative from

 each functional area, including operations, technology, support, engineering, finance and IT. Even those not directly involved in the project may contribute something unexpected and keeping everyone informed will help avert interdepartmental snafus. You don’t want a cloud migration coinciding with IT moving finance to new servers.


Start developing the project-success metrics by identifying measurable impacts, e.g., reducing manual intervention (hands-on time) by x, increasing operational capacity by y. Maybe you want to contain the cost of maintaining a physical infrastructure, or eliminate poor equipment utilization rates and optimize capital expenditure-to-usage ratios. Just consider what can be measured going into the project so you have a reasonable notion of your baselines.


Talk to the cloud-service providers who can align their services with your goal. Remember that the processes throughout each sub-workflow are offered as pay-as-you-go microservices within the cloud from a variety of vendors. This minimizes the time spend on vendor selection, takes a huge capitol risk factor off the table and minimizes vendor lock-in if the selected technology doesn’t perform as expected.


Familiarize yourself with this new pay-as-you-go provisioning and billing model. Cloud-native automation enables rapidly provisioning services as they are needed. The cloud cost model is a radical departure from the facilities cost model, so it will be worth the time to get acquainted with it.

city background_1217x961.png

Media Supply Chains

by the Numbers


  • 70% improvement in time to market with 85% cost saving

  • 83% faster to process content, at less than 10% of the cost

  • 23% increase in revenue, operating costs decreased 25%

  • 80% reduction in unplanned content touches

  • 40% reduction in logistics load


Learn more on our blog.


Step 4: Implementation


This step involves:

  • creating the implementation team

  • setting the timeframe

  • testing, tweaking and launching


Once the migration strategy is nailed down, the focus can shift to implementation. It should be fairly straightforward to create an implementation team since by now you know who is most engaged. Identify—either train or hire—an in-house cloud administrator. This could be someone already in IT. Cloud admin may not be a full-time job, but it helps to have someone on staff who understands how the cloud operates.


The team can help catalog a few things—e.g., network bandwidth capacity, where to apply encryption and what security requirements are indicated. Along the way, have them establish an ongoing governance process to keep the strategy on track, and to continue communicating with stakeholders so problem areas can be identified and mitigated quickly. The process will involve developing technical, connectivity, resiliency and failover standards, plus the practices for maintaining those standards. Investing the time to establish a governance process early on will pay off as migration continues because it can be adapted across all phases of a migration and beyond.


At this point, you may want to sketch out data-sourcing protocols for capturing metrics. Data has its own data in the cloud, so it’s helpful to think about just how granular you want to go. Having access to the cost of every individual process on each piece of content doesn’t mean this data has to be continually compiled. Don’t base these protocols on the available data, but rather the data necessary for establishing metrics and achieving the desired outcome.


Establish a realistic timeframe with regular progress reports due from the implementation team. When it comes to setting a date to take the new system live, shoot for the least busy time of year—if you have one. Account for holidays and other possible disruptions, including those surprise mandatory workplace training sessions triggered by some new regulation.

This is where having thoroughly communicated the migration plan across all departments—including human resources—comes in handy. The move may not have direct impact on every department, those departments may have a direct impact on the move.

Back up existing servers and data if that process isn’t already taking place automatically. Test connections, individual components and the system in total to confirm reliability. Make sure content is presenting correctly and the environment is secure. Check for any issues with end users so the appropriate tweaks can be made.

When you’re ready to go live, route content through existing and new processes and observe the difference. Note where automation eliminates the need for manual intervention. This dual-workflow phase allows for fine-tuning while de-risking the initial migration, plus it demonstrates proof-of-concept internally and creates a reference system for the continued roll-out.


Keep communication lines open. Expect to talk a lot, particularly in organizations where departments that haven’t worked together before. Then commence the migration.

Step 5: Measure, Adapt & Repeat

This step involves:

  • applying metrics

  • assessing the outcome

  • adapting the process for the next round

Once the migration is complete, revisit to the primary goal set in Step 2. Apply the key metrics developed in Step 3 with the data identified in Step 4.

Get post-migration feedback. E.g., how long does it now take to process one hour of content from beginning to end? How many manual interventions are now required? What is the overall cost of my supply chain versus the pre-migration model? How much more content can the team handle now compared to before? Is their time now focused on more critical or creative endeavors? What is the cost of change?


The cloud-native ecosystem allows you to constantly evolve and adapt as the business requirements change. This unprecedented visibility into near real-time processing costs will enable data-informed business decisions.

The operation can more opportunistically take additional volume deals where they make sense rather than whether or not you have the capacity to deliver them. This ability to get to revenue faster, with more overall capacity and no down time fast-tracks your ROI.


All of this information, along with the experience of navigating a full migration cycle, will form the groundwork for the next sub-workflow migration—or full immersion where it makes sense. At this point, you can identify the methods and practices that worked well and determine how to apply them to other areas of the media supply chain. In rolling out cloud-native content receipt, for example, you may discover a technique that would have a transformational impact on content delivery.


That’s part of the beauty of this migration model—it’s iterative. Once you have migrated your initial sub-workflow, you can modify and adapt the methods you used to make the next one even more efficient and streamlined. This is where the governance process will come into play and also where it will continue to be refined.


So now return to Step 1, identify the next area of the workflow for migration, and go from there.


Contact us to talk about your supply chain and cloud migration.