Geek Speak

6 Posts authored by: ather_beg

Cloud migration follows the same principles as any other complex task. With methodical planning and appropriate preparation, it can be a smooth and painless experience. While “divide and conquer” can have negative connotations, it’s a popular technique in computer science and can be applied to program management equally.


Assuming a migration was planned as such and all workloads are in the cloud now, does that mean the job is done? Absolutely not! There are several tasks that should immediately follow, some of which should become iterative processes going forward.



Immediately after migration, it could be all high-fives on a job well done. However, it’s crucial to do a clean-up immediately after, including shutdown and removal of any redundant systems, severing of superfluous network connectivity, and switching to production status of relevant applications on the cloud platform.


These actions are extremely important from an operations standpoint. The cost of running those extra resources is one thing, but those systems are easily forgotten over time. While they exist, they only cause operational confusion and security issues. Action should be taken to do a controlled but prioritized decommissioning of such systems and connectivity.



Once closure has happened and the platform is stable, evaluate if the migration was successful and achieved all it was set out to do.


The first point of reference is the business case that was formed as part of the project initiation phase where all stakeholders agreed it makes sense to migrate to a cloud platform. The other one is the list of KPIs (key performance indicators) that were defined as part of the audit that was defined just before carrying out the migration.


The latter is tangible proof of what was gained from the whole exercise. You should be careful that the measurements are “like for like” and the target objects will exist in their current form post-migration when defining the metrics, so there’s no confusion. Such evaluation and documenting before and after the migration is important as it keeps the team honest about their goals and any decisions made. At the same time, it also makes success undeniable.



Sizing of machines is one area where you should err on the side caution and oversize. That combined with the fact that in the early days applications tended to live in both environments, increases the running costs in the short term. Once the dust has settled, it is time to focus on optimizing for costs. Most cloud platforms offer discount pricing for infrastructure and native tools to determine where such savings can be made.


This is a quick and easy win. Furthermore, it’s easy to identify machines that will be required permanently and are good candidates for discount pricing by committing a certain amount to the vendor. In some cases, further savings might be possible by standardizing certain types or family of instances. A review should be done every year to determine how many resources can benefit from such discounts.



Speaking of cost optimization, another way is to refactor applications so that they can benefit from on-demand resource provision such as “function as a service” architectures or even stateless applications where infrastructure can be deployed for the duration of the job and destroyed thereafter.


Major cost efficiencies can be found using cloud-native technologies and methodologies. The best part is that due to the nature of the public cloud, such refactoring can be done in isolation and tested at full-scale in parallel.


Small and manageable improvements can be made over time to gain those efficiencies and that work should become part of an ongoing process to improve applications.



In the coexistence phase during migration, security policies have to allow traffic and system access between applications on both environments. Those policies need to be reviewed immediately after decommissioning of the “legacy” side of the application.


There could be a tendency to wait until all legacy applications are decommissioned but by doing so, you’d be introducing a security risk for the duration of the migration. While it can be a tedious process, any security breaches will end up consuming even more time, so it’s best dealt with as soon as possible. The security review shouldn’t be limited to just the legacy workloads. Security for cloud platforms is very different from traditional platforms, and migration provides an opportunity to review the capabilities available and take advantage where possible.


Center of Excellence

The migration team goes through many highs and lows during this process. That not only improves bonding but also develops a lot of skill and knowledge.


That knowledge is priceless, and it would be a shame if that team disbands completely and goes back to their “day job.” Technical members of the team will likely continue with the new platform, but other members will also have precious knowledge of the whole journey and shouldn’t be ignored. It makes sense to preserve that knowledge and experience by keeping the team as the “Center of Excellence” for the long term. It should reserve time and meet on a regular basis for strategic discussions and decisions going forward.



Migration to the cloud is no mean feat, but once achieved, it opens up so many possibilities to morph the infrastructure and tools into something in line with modern-day architecture.


This list is by no means exhaustive but does give a good start. As cloud technologies and skills to use them develop, only the sky is the limit—no pun intended!

Migration to the cloud is just like a house move. The amount of preparation done before the move determines how smoothly the move goes. Similarly, there are many technical and non-technical actions that can be taken to make a move to the cloud successful and calm.


Most actions (or decisions) will be cloud-agnostic and can be carried out at any time, but once a platform is chosen, it unlocks even more areas where preparations can be made in advance.


In no particular importance or order, let’s look at some of these preparations.



Some workloads may not be suitable for migration to the cloud. For example, compliance, performance, or latency requirements might force some workloads to stay on-premises. Even if a company adopts a “cloud-first” strategy, such workloads could force the change of model to a hybrid cloud.


If not done initially, identification of such workloads should be carried out as soon as the decision on the platform is made so the design can cater for them right from the start.


Hybrid IT

Most cloud environments are a hybrid of private and public cloud platforms. Depending on the size of the organization, it’s common to arrange for multiple high-speed links from the on-premises environment to the chosen platform.


However, those links are quite cumbersome to set up, as many different parties are involved, such as the provider, carrier, networking, and cloud teams. Availability of ports and bandwidth can also be a challenge.


Suffice it to say that lead times for an end-to-end cloud migration process typically ranges from a few weeks to a few months. For that reason, it’s recommended to prioritize identifying if such link(s) will be required and to which data centers, and get the commissioning process started.


Migration Order

This is an interesting one as many answers exist and all of them are correct. It really depends on the organization and maturity level of the applications involved.


For an organization where identical but isolated development environments exist, it’s generally preferred to migrate those first. However, you may find exceptions in cases where deployment pipelines are implemented.


It’s important to keep stakeholders fully involved in this process, not only because they understand the application best and foresee potential issues, but also so they’re aware of the migration schedule and what constitute reliable tests before signing off.



Most organizations like to move their applications to the cloud and improve later. This is especially true if there’s a deadline and migration is imminent. It makes sense to divide the whole task into two clear and manageable phases, as long as the improvement part isn’t forgotten.


That said, the thinking process on how to refactor existing applications post-migration can start now. There are some universal concepts for public cloud infrastructure like autoscaling, decoupling, statelessness, etc., but there will be some specific to the chosen cloud platform.


Such thinking automatically forces the teams to consider potential issues that might occur and therefore provides enough time to mitigate them.



Operations and support teams are extremely important in the early days of migration, so they should be comfortable with all the processes and escalation paths if things don’t go as planned. However, it’s common to see organizations force rollouts as soon as initial testing is done (to meet deadlines) before those teams are ready.


This can only cause chaos and result in a less-than-ideal migration journey for everyone involved. A way to ensure readiness is to do dry runs with a few select low-impact test environments, driven by the operations and support team solving deliberately created issues. The core migration team should be contactable but not involved at all.


Migration should only take place once both teams are comfortable with all processes and the escalation paths are known to everyone.



Importance of training cannot be emphasized enough, and it’s not just about technical training for the products involved. One often-forgotten exercise is to train staff outside the core application team, e.g., operations and support, about the applications being migrated.


There can be many post-migration factors to consider that make it necessary to provide training on applications, such as application behavior changes, deployment mechanism changes, security profile, and data paths.


Training on technologies involved can start as early as the platform decision. Application-specific training should occur as soon as it’s ready for migration but before the dry runs. Both combined will keep the teams in good stead when migration day comes.



Preparation is key for a significant task like cloud migration. With a bit of thought, many things can be identified that are not dependent on platform choice or the migration and can therefore be taken care of well in advance.


A successful cloud migration sometimes depends on how many factors are involved. Reducing the number of tasks required can mean less stress for everyone. It pays to be prepared. As Benjamin Franklin put it:

  “By failing to prepare, you are preparing to fail.” 

One is spoiled for choice when it comes to choosing a cloud provider. Cloud platforms have come a long way since their humble beginnings and now offer a myriad of services to suit most use cases customers might have. The question on every CTO's mind is, “Which cloud platform is the best for my business?”


So, what should you look for when choosing a cloud provider in 2019? Let’s look at some common factors about how to choose the best cloud computing option.




This is where most cloud platform evaluations start, as the desire to save on costs is natural to any company. It also makes sense as the cloud is consumption-based. The cheaper the cloud platform services are to start with, the less recurring cost it will have.


If an audit of existing infrastructure has been carried out, estimated costs for an equivalent deployment on the different clouds in scope shouldn’t be too difficult. Network traffic charges and applications might not be as straightforward, so some guesstimates, based on realistic assumptions, might be necessary.


However, bear in mind that even if it seems cheaper, those costs are estimates at this point and might change as a result of the eventual design. The same cloud might also become more expensive if the infrastructure profile changes in the long term, perhaps due to refactoring.


Existing Infrastructure


Cost should never be the only factor considered for this decision. There are many others, and existing infrastructure is among them.


Traditional infrastructure has grown organically for every company in the past. Platform and technology choices were driven by the needs of the company at the time. Some went the open-source way, while many had no choice but to have proprietary software.

When moving to the cloud, that history can influence the choice of platform. This is especially true for larger companies that might have enterprise licenses for software, translating into discounts on the platform and lowering costs.


Existing Expertise


Existing infrastructure also affects the expertise that exists within the teams that will be working with the chosen platform going forward. It’s important to take that into consideration, given that learning a new cloud platform takes a lot of time and effort.

Consider that the teams have worked with their existing environment for years to develop their expertise, but for the new platform, they’re expected to be up and running in a fraction of that. It helps if the platform chosen reuses at least some of their existing expertise.


Future Roadmap


What will application development and infrastructure look like in the future? Platforms aren’t changed frequently, and the ones that fit that vision should weigh heavier  than the ones that don’t when considering a cloud platform.


Be careful here. Popular opinion might put one cloud platform in front of the other for certain services, but is the company likely to use those services, and if so, would it use the features that differentiate it from other platforms?


Services Offered


Assuming the migration needs to happen soon, does the cloud platform cover (or provide equivalents for) all the services required today? Keeping the on-premises environment and going hybrid might be an option if some applications are not suitable for migration or too difficult to refactor, but it’s safer to look for a cloud provider that can provide the needed services from the start.


One significant consideration here is database platforms that may not have a natively licensed version on that platform. A workaround for that problem is to migrate to another cloud-based database platform, but it’s difficult, especially in the timescales for migration, and comes with a certain amount of risk. Another way is to host it on dedicated instances, but that’s an expensive and inflexible workaround, and is best avoided.




Some organizations have their sights set on a multi-cloud deployment, which, if successful, reduces the risk of choosing the wrong cloud. It might work, but only if there’s existing knowledge of those cloud platforms and compelling reasons to do so, e.g., some functionality that a platform excels in.


However, if there’s no existing knowledge and experience, then it could be a risky strategy. Becoming comfortable with one cloud platform is difficult enough with all the innovation and options  available. Adding another platform will stretch the teams too much, without much gain in capability.


A better way is to focus on one platform and do it really well and in-depth. Cloud concepts translate well between all, so there’s no reason the other platform can’t be added to the overall infrastructure later.


In the meantime, applications should be built on platform-agnostic infrastructure with standard interfaces between services and that should allow cloud mobility when more options become available.




Picking the best cloud provider is no easy task and a lot of thought goes into it. Comparative cost is never the only factor, and there are many other considerations that can influence the decision.


There’s so many choices available that it’s hard to find a use case that cannot be catered for by the cloud platforms available today. While it makes the decision-making harder, it’s a nice problem to have.

All successful cloud migration projects start with up-to-date knowledge of a company’s current infrastructure and application landscape. While it may seem obvious, many organisations don’t have a clear picture of what’s running in their environments. This picture helps the migration effort both before and after the migration. I’ll mention how in a bit, but first, what should we look for?


One obvious category is information about the workloads themselves. Almost all platforms come with reporting tools that tell you about the workloads running on them. That information, extracted from all platforms and kept in an easily manipulated format, such as a spreadsheet, forms the initial scope for migration.


Networking design will undoubtedly change beyond recognition as part of cloud migration, but it’s crucial to have an in-depth understanding of the existing topology, the rationale behind that design, type, and quantity of traffic that goes over the various links.


Knowing the complete breakdown of the costs of running the existing service is a must. Hardware and software costs for the platform and data centre costs are obvious ones, but the headcount required for operations is often forgotten. Make sure that they’re also considered.


What about who owns which service and who is the technical authority for it? These are often different people with different priorities. It’s not enough to just put any names there. It’s very important that the named individuals know about and agree to hold those roles for that service.


Pain points are excellent indicators of what are important issues to resolve. For example:

  • How long does it take for operations to deploy a machine?
  • Does the application scale under load? If so, what are the response times?
  • How long do the developers have to wait before they get their test platforms?
  • Are current processes automated or do they require manual intervention?


These measurements define your KPIs (key performance indicators) and will be used later to measure success. Those indicators must be well-defined, and their values should prove categorically if the state has improved or deteriorated. Once defined, values of those indicators should be carefully documented for the pre-migration state, with careful consideration that no correction is carried out before the measurements are taken. 

Benefits Before Migration

Once the audit is done, the picture starts to become clearer. Let’s take the infrastructure spreadsheet for starters. Initially, it will be a crude list of workloads, but with a bit of thinking, the team can determine how many of them should be in-scope to move. They could be all production and development machines, but what about test machines?


It could also be that the hosting platform is creaking under the workload, increasing the urgency to migrate, to avoid capital investment into more hardware. This audit may identify workloads that are forgotten but can be removed to reclaim precious resources, thereby creating breathing space and buying more time to migrate.


Before the design phase, having all networking information in-hand is extremely important, as networking costs are calculated very differently in the public cloud. Not only are they highly-dependent on the design, but they can influence the final design.


It’s also a good opportunity to look at workloads to see if there are any unusual machines in terms of resource allocation or licenses that may not fit nicely when moved to a public cloud platform. Some rationalisation in that area can help reduce pain when going ahead with the design.


If not already done, this exercise also gives a good estimation of potential infrastructure costs on the various cloud platforms and can also feed into business case conversations.

Benefits After Migration

Going through the audit process makes it easier to carry the habit through into the new platform, especially if it proved to be useful. Data gathered can also be extended to contain additional data points that might have been useful to have initially but were only discovered as part of the migration.


In the short term, after-migration costs are seen to increase. That is because in the initial stages of migration, both source and destination environments are running in parallel. In such situations, having the audit done with exact cost breakdown helps to explain that behaviour.


A key milestone in the migration project is to show the business that you as a team have achieved the goals that were set out in the cloud migration business case. That’s where the effort spent in defining those KPIs and documenting the values comes in handy. New data returned into those KPIs post-migration becomes the determining factor for project success or failure.


Having the current, complete, and accurate data in-hand is the first practical step in starting the migration journey. That should contain data from all the sources that will be affected by the migration. Most importantly, it should contain the KPIs that will determine success or failure and their measurements before and after migration.


It’s important because while one can announce a migration to be a success, as W. Edwards Deming said:

“Without data, you’re just another person with an opinion.”

Great! You’ve made the decision to migrate to the cloud. What should be the first step towards that goal? The answer is: defining a cloud migration team that understands the vision, has skilled members to carry out required tasks, and is available to contribute as and when required.


The best compliment for an IT team is invisibility. It’s a sign of a well-oiled machine that provides everything that a business needs, anticipates problems, and rectifies them before they occur.


A cloud migration team is no different. It typically consists of members from various business units from within the company (although external skilled consultants can also be brought in) who are aligned to very specific and clearly-defined roles. If done correctly, even the most complex landscapes can be migrated with ease and transparently.


Think of the whole process as a drama: there’s a plot and colourful characters that play specific roles. There are ups and downs during the whole process. Occasionally, people get emotional and tantrums are thrown. The main thing is that by executing their role well, each team member works towards a happy ending, and by playing their part faithfully, that’s exactly what they get.


Essential Roles

The main character of this drama is the cloud architect. Appointing someone to this role early is essential. Leading the mission, this person is proactive, defines the scope and strategy, and identifies the wider team that will contribute towards a successful migration.


A great source of contributors is the group of stakeholders from the business, platform, security, and operation functions, who by now are already sold on the idea. That would indeed be the case if management has gone through evaluating the business need to go to the cloud and was part of the approval process. Not only can they provide resources to the project, but they also have the unique view from their own functional groups’ perspective that ensures all important bases are covered.


Commonly seen as the villain, the project manager is an extremely important role that keeps the cloud architect and other players on the straight and narrow. This role is not just about making a schedule and keeping everyone on time, but also to help prevent scope creep and foresee resourcing issues.


It’s easy to forget the “understudy,” but we are all humans and can fall ill unexpectedly—sometimes for long periods. People can also switch jobs. That can have a major impact on progress, especially if that person held an important role. Once the process starts, it’s important to keep the momentum going. That is made possible by having multiple people shadowing key roles where possible.



Nobody wants a bad actor in a drama. It can annoy the audience and derail the entire performance. Team members not suitably skilled for the role they’re assigned are likely to underperform and drag the whole team to a standstill.


That said, everyone wants to be a part of something special, and often, they are prepared to put the extra effort in to learn new skills. Career development and a sense of achievement by being part of a success story is a great motivator too.


The key is to identify the gaps early and send team members to appropriate training as soon as possible. The sooner this step is taken, the less pressured they feel when the project starts, and they can provide valuable input to important decisions early in the process.



Imagine what would happen if a character drops out from a performance every now and then. Worse, if more than one does it. Would that play be a success?


The same is true for a cloud migration project. While it can be a huge drain on a company’s resources, the commitment to provide the personnel necessary to carry out assigned tasks all the way to the end, is critical before embarking on that journey. Not doing so creates huge dependency issues that are hard to resolve and forces the entire schedule to go out of shape.


The day job doesn’t stop with a project like this, but a portion of time should be committed and prioritised. It’s almost impossible to commit resources full-time to a project, but as long as availability issues are communicated clearly and well in advance, the team can work around it.



The success of a migration project is highly dependent on the people assigned to the project. It is something that is interesting but also challenging at the same time. Delivery of a high-quality migration with minimal or no disruption requires a skilled team, clear roles and responsibilities, and the time commitment to think and plan properly.


Most importantly, we all know the magic that happens when all the characters are having fun. That production always becomes a knockout success.

Public clouds provide enormous scale and elasticity. Combined with a consumption-based model and instant deployment methodologies, they provide a platform that is extremely agile and avoids locking of precious capital.


Surely it’s a no-brainer and why every company has plans to migrate workloads to the cloud . In fact, it is so obvious that one actually needs to look for reasons why it won’t be a good idea. It may seem counterintuitive, but it is one of the most important steps you could take before starting on your cloud migration journey.



Regardless of size, migration could be a huge drain on time and resources. One of the most cited reasons for the failure of a cloud migration project is: “The project ran out of steam.” Such projects typically lack enthusiasm, resulting in slow progress. Eventually, corners are cut to meet deadlines and the result is sub-standard migration and eventual failure.


Humans are wired to be more interested in doing something where there is a tangible benefit for them in some way. In addition, they are more likely to remain committed as long as they can see a goal that is clear and achievable.



Migration is not a single-person job. Depending on the size of a company, teams from different business groups are involved in the process and have to work together to achieve that goal. To ensure success, it is critical to get the backing of all the stakeholders through an honest evaluation of the business need for migration to the cloud. It must be backed by hard facts and not just because it’s fashionable.


This evaluation goes hand-in-hand with the problems a company is looking to solve. The most effective pointers to them are the existing pain points. Are costs for running a particular environment too high? Is the company becoming uncompetitive due to lack of agility? It might even be a case of developing the capability to temporarily burst into the cloud when an occasional requirement comes up, instead of locking capital by buying, provisioning, and maintaining own equipment.



Armed with those pain points and relevant data gathered, analysis can be done to determine if cloud migration is the only pragmatic solution. SWOT is a great framework for such an evaluation, and is used by many organisations for strategic planning.


It’s important to have all the key stakeholders present when this exercise is done. This ensures that they are part of the discussion and can clearly see all arguments for and against the migration. Those stakeholders include leaders from the infrastructure and application groups as well as from the business side, as they have the best view of the financial impact of current issues and what it would be if action is not taken.


The focus of this analysis should be to identify what weaknesses and threats to the business exist due to the current state and if migration to the cloud will change them into strengths and opportunities. With prior research in hand, it should be possible to determine if the move to the cloud can solve those issues. More importantly, this analysis will highlight the financial and resource costs of the migration and if it would be worth that cost when compared against the problems it will fix.



Effort spent at this stage is extremely valuable and ensures the decision to migrate to the cloud is robust. Furthermore, the analysis clarifies the need for action to all stakeholders and brings them on board with the vision.


Once they see the goal and how it will solve their business problems, the result is a commitment from all teams to provide their part of the resource and continual participation in the project until its successful completion.

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.