Plan migration, engage product teams

Migrations tend to get stuck. While migrations seem to start off with good effort, This does not eliminate the risk that it can get “stuck in the mud” over time. Two things can help engineering team to come out and move forward. This blog follows the previous blog. Introdution to migration what

• Ruthlessly prioritize. Prioritizing is easier said than done when working with highly autonomous teams. 
• Matured engineering culture A company’s engineering culture is going to play a big role in how the [migrations being stuck] problem is perceived.

While technical leaders may start with the ideal assumption that business stakeholders understand that existing systems and approaches require upgrade as part of growing adoption of the solution. The assumption may not always be true for software and architecture upgrades, while the business leaders are happy with upgrades to cope with extra load, more use cases, or more constraints.

In the process of an accelerated pace, be open to the possibility that both business and engineers forget  to prioritize the requirement to migrate/evolve old systems or old approaches to a new one on a continual basis. 

Planning  as engineering team.

While engineering teams start to plan how migration needs to happen, their first step is to Influence and  impress the business team about the importance of migration and get their buy-in to develop migration POC.

Prior to the start of  migration, every stakeholder should agree on the priority and relative importance of the migration project and when potential downtime periods are feasible. Negotiate as required

Present migration as a new project to business for budget approval before the engineering team invests high efforts. Spend time to bring business on the same page by making them understand risk and efforts and uncertainty related to migration. For me, it is a great start for migration when product and business stakeholders actively engage with engineering teams on migration and facilitate the curation of  product backlog.

When an engineering team is composed of multiple sub-teams, setup creating a communication channel from day one to enable easy collaboration across teams earlier, to eliminate and discuss more risks at the planning stage..Over time, one team can offer other teams live office hours to support debugging.  Assume the presence of debugging logs. 

Presence of automated tests helps to identify gaps and reduce pain of migration gaps. If automated tests are absent or existing tests fail to provide sufficient  test coverage, it is better to demand more budget to the business team for writing automated tests. I would prefer the engineering team demand even prior to the start of migrations. 

When teams start automation and migration, life is easier. When things proceed at a fast accelerated pace, it is quite possible that more tests will fail. 

In a 150 member large team, observed changes made by one team  broke  (unit tests pass) integration tests with other modules. One can evaluate based on organization context 

• Plan for a central mechanism to Run CI tests on a daily basis and notify results to teams on a daily basis
• Influence leadership to sets goals for all the team that failure of integration tests needs to be  fixed  quickly. 

This means migration demands additional efforts be invested on a continuous basis to provide  migration efforts higher priority in their execution. Yes migration efforts are less of a priority to support production or customer field issues or the support required for new customer on-boarding. 

Engage product teams in Planning

While migration work has been  considered to be engineering heavy, it becomes  more simple when engineering teams get product managers to get involved in migration and create   a win-win plan of migration that is owned by the organization, in addition to the engineering team.

A product manager, who is curious to learn and be aware of technical challenges of migrations, treats other engineers involved to perform migration work as customers, not just as fellow developers.

 Product Managers can

• influence engineers to adopt a much-needed customer-centric approach that is  always observed to be missing when engineers only have to perform heavy lifting of  migration.
• Think about the  impact of  migration on the solution offered to customer, measure and evaluate the impact on regular basis and have all teams to be on the same page
• Think about whether  migration impacts vary across multiple user personas and the impact on product operations and customer success teams, gather feedback and communicate value.
• Participates in engineering discussions to create customer centric migrations road-map and influence priorities on backlog items. The more migrations plan gets discussed  in the early stage or ahead of time, engineers gets benefit to visualize which migrations are scheduled  for earlier and which gets scheduled  or future quarters and plan development work better

Here are few ways to start visualizing how product managers can facilitate the engineering team and influence with respect to migration

• Understand how the team decided to build a new system and facilitate the migration strategy by setting migration goals.
• Enforce  test of migration code, scripts and procedure before roll-out. Alpha and beta tests are common with migrations, just like they are for products.
• Create training programs, where it makes sense. Work with engineers to create training resources and programs.
• Explain the value of the migration to customers.  Each migration communicates the values of this migration, often with the help of product marketing managers (PMMs).
• Connect with customers’ pulse. PMs know customers and do things like segment customers and schedule migration based on segments and risks.
• Present a competitive angle to customers about migrations by creating right positioning for migrations.

Product manager can think deep about challenges die to migration for product operations and customer success team and can bring that perspective to engineering teams

• Create as many  automation scripts and approaches as possible, to be leveraged by operation teams to enable smooth customer migrations.
• Engage operation teams, to discuss the best casein worst case scenario that is envisioned  by the customer success team wants. Should customers be informed about upcoming migration or when they should be informed of the same? What type of documentation are required for the customer success team to support successful migration?
• Discuss whether the customer success team perceives scenarios where rollbacks may be required.  If required in future, have you planned how to perform rollback with less impact on the customer

When engineering teams are siloed, we need to acknowledge human bias that engineers may notice that something is going wrong with  migration at early stages only when this rollout is already midway. Here is where  rollback mechanisms may be required. 

Some pointers for engineering teams to ramble based on their organization context. Feel free to discuss these pointers with product team and make them your partner in migration.

Do we need this to feel safe about migration? If there is a need to pause migration or something unexpected props up, can we allow for a rollback to happen ?  This can be complex and tricky as the roll-out and rollback need to be synchronized on the client side and on the server side. To put the question another way, Do we need a kill switch created as part of the migration?   When the kill switch is activated, a full rollback to the pre-migration state occurs.

Kill switches need not be completely automated. It can be a set of documented steps that can make the impact of kill switch happen.

There can be staging servers for new system post migration where engineering teams migrate data from the old system. Some customers can even connect and verify all is well before asking all customer end-users to move to the new system.

In banks and financial institutions, the life cycle of processes runs for years and it may be decided not to migrate all data from the old system to the new one, when a new system replaces the existing system. One way is to provide the end-user access to both new and old system, and allows end-users to view new transactions in new system and continue to view old transactions as part of old system

Do we need migration to be observable?. How will product managers identify when  regression in business metrics occurs during the migration?  Do we measure conversion rates during the migration.?

Do we need migration to be measurable? reduces the  number of decisions made by the team in a state of uncertainty and ambiguity and acts as data-driven guardrails in place for migration.  This removes the guesswork done as part of engineering planning for migration roll-out milestones. Better to ensure that there is  clarity on when the next ramp up in migration efforts is required  and how much  unplanned increment in migration efforts can be supported  confidently.

How much to share about migration to business teams The objective is to raise  migration to be  an organizational initiative, rather than a silo-ed attempt of the  product and engineering team.  if product manager is engaged with migration efforts, he can facilitate this communication of migration updates to business teams.

The engineering and product team can adopt processes to provide regular migration progress related updates to product operations, customer success and business teams. When you share with a business team, it helps to enlist the help of customer success teams and operations teams to get  early feedback.