Previously, my colleague George, wrote about Phased Migration For Complex Systems, where he discussed using phasing to manage risk. Now let’s talk about carrying that good practice forward.

Reasons to migrate

If you run a SaaS business, there could be many reasons why you would want to be operating in the cloud. If you’re not there yet, those reasons should be pretty high on a CTO’s To-Do list. For example:

• Reducing overheads associated with managing physical infrastructure
• Reducing time spent upgrading or backing-up servers and databases
• Provide an easier route to taking your business to other geographical regions
• Be more nimble with trying different architectures
• Not having to reserve CapEx and then wait for equipment to arrive

It’s possible that this will be a simple process, where a straightforward “lift-and-shift” operation can be performed to host a complete system in AWS. Often, when clients talk to us about systems and platforms that they wish to migrate which are more complex, we recommend planning a series of migration phases.

Staying small

Choosing what to migrate for the initial phase is important. But for the second phase, the scale of the migration matters most.

The “second system effect”, as coined in “The Mythical Man-Month” by Frederick P. Brooks, Jr., is a phenomenon that can occur when a team is developing a new system or product, and they become overly ambitious with the new system, resulting in a complex and bloated system that is difficult to use and maintain. This can happen when a team becomes so focused on creating a perfect system that they lose sight of the original goals and requirements, or when they try to include too many features and capabilities.

This can directly relate to the process of phased migration of a system to the cloud. An initial phase may simply consist of a particular service, data store or website, and then this goes very well with smiles all around. Buoyed up by their success, the team earmarks everything else to be moved or re-architected for AWS and they’re off to the races. Fast-forward to a year later, they still haven’t finished and many of the people responsible for both the old and new systems have either left their jobs or the project.

However, the initial phase is successful precisely because it is small; the subsequent phases are most likely to fail because they aren’t structured or sized in the same way.

A similar situation can occur when the components being migrated are reimplemented/re-architected en-passant; the resulting work blowing up into a huge project as it mercilessly eats up your development budget. As an alternative, move the component as directly as possible and then reimplement it.

It is also tempting to perform a great deal of foundational work in the target environment which is not essential to migrate the actual business value that is within scope.

The goal with slicing-up the migration pieces is to balance two concerns:

• The interest that will be taken in seeing value from the migration (i.e. by a board of directors)
• Managing how the scope of work creeps up in size

Enfranchise and evaluate

Ensuring that you keep focus on delivering value from a migration project can be complex. Two things that can help are enfranchising stakeholders and evaluating the migration plans to a suitable standard.

The planning and implementation of the migration should involve all relevant stakeholders and ensure that their feedback is considered so that the team is able to incorporate their input and ideas into the migration plan. This in turn gives any stakeholders from the pre-migration systems a bridge into the new world which will hopefully reduce attrition of attention.

Further, if the plan for a migration is not adequately assessed, there is a risk of wasting time migrating parts of systems that offer no or little value. This is especially true for a phase that becomes bloated with goals to move All The Things. To combat this, find smaller packages of work that have independent value.

The value of a package of migration work doesn’t have to accrue to end users. If the migration of a component improves information security, or cuts the time needed in a development cycle, that’s OK so long as someone owns the value and can make the case for it. The flip-side of this is that if nobody is willing to own the value of a package then don’t start its migration.

Set your own goals

It’s important to define goals and requirements as early as possible.

Stakeholders can come together in a well planned workshop which can promote teamwork, support business robustness and increase longevity of outcomes. As a hidden bonus it can help remove silos and allow collaboration between those that often don’t have the opportunity to.

When we run these kinds of workshops, we aim to explore through discussion the business, background and where the workshop fits within your short and long term strategies. It is important to us that any solution that is created during the workshop is agreed upon by its stakeholders and links directly to the desired business outcomes. This is even more critical for migrations where providing value at each stage is very important.

Amongst other things, we should be able to answer the following questions by the closure of the workshop:

• Do our designs link directly to business objectives?
• How does it fit in with the overall cloud architecture?
• What are we not delivering? And why?
• Have the impacts of any proposed changes been scoped and identified?
• What are our very first next steps and who will complete those tasks?
• Who is accountable for project velocity?
• Who are the stakeholders and how do we communicate daily? Weekly?
• How will we collaborate on implementation?
• How do we measure success and velocity / progress burn-down?

Through the workshop process it should be possible to produce a plan for one or more components that should be migrated, safe in the knowledge that all the stakeholders are in agreement and have been heard.

Once you have a plan, establish a set of Key Performance Indicators (KPIs) to measure the success of the migration. This can help ensure that the phases are focused on achieving specific business objectives, and that the team remains focused on meeting these goals, rather than accidentally hitting them into your own net.

Agile development and DevOps practices can be used to manage the migration, complete with regular reviews that allow opportunity to adjust the migration plan based on feedback and performance data. This can help the team stay focused on delivering value and meeting the goals of the migration, and avoid becoming overly focused on adding unnecessary features or capabilities.

Split the workload

Systems being migrated are commonly single, complex monoliths. Sometimes the technology may be trying to achieve things that off-the-shelf or managed technology can do, allowing the option of reducing the effort of the migration by buying-in equivalent components. Load balancing, running a proxy and running message queues are good examples where typically the Cloud-managed equivalent components will vastly reduce the complexity and security footprint of an application, potentially making things like High-Availability, scaling or patching something that happens automatically without Ops effort.

Provided that there is a link to delivering value, splitting a system up like this enables the ability to work in iterative phases. We can help you identify those split points through workshop sessions.

Use the strangler fig pattern or another incremental approach for migration. This can help teams avoid the temptation to create an ideal outcome in one go, and instead allow the contributors to gradually migrate the system, testing and validating each component before moving on to the next.

This approach can help reduce the complexity and risk of the migration by allowing the team to gradually transition their systems and applications to the cloud. Comprehensive testing of each piece of functionality helps ensure the overall migration is successful. Above all, the use of this kind of iterative approach avoids the potential costs and disruptions of a “big bang” migration.

Add more code

Most often you’d want to reduce how much code you look after, if possible, especially if the goal is to have the end-user experience staying the same.

Sometimes, when you migrate, it’s best to write more code. This is especially true when using Infrastructure as Code (IaC) to replace existing steps that are fully manual; allowing you to reap the benefits. You could code it on both the old and new systems, or switch over from a manual to an automated process.

Wrap-up

These techniques can help you avoid some of the pitfalls of complex and ambitious migration projects. Keeping work packages small and focused on specific business objectives, avoiding the temptation to add unnecessary features or capabilities will all help things move smoothly. This can help the team create a cloud-based system that is stable, secure, and easy to use and maintain, providing real value to the business in a cost-effective way.

---

Our team knows how to manage the risks around moving data to the cloud. We also know how risky it can be if you don’t have a cloud copy of your critical data. Book a free chat to find out how we can help.

---

This blog is written exclusively by The Scale Factory team. We do not accept external contributions.