Whether you call it Lift and Shift, Rehost, Re-platform, Transform, or Refactor it essentially means you are looking to spend money now to save money later. The business events that drive the change may vary, but the needs are the same, to move off what you have and into something you want, or believe you need, to satisfy your business demands. The “want” and “need” essentially boils down to saving or making more money.
I bet you feel that “the cloud” will address the money question because of the wonderful benefit of, <insert cloud marketing slogan here>. Hyperscale providers speak of elasticity, scalability, availability, reliability, optimized costs, improved performance, and innovative solutions. They will speak of the importance of Kubernetes, Containers, micro-services, statelessness, AI, ML, and highly secured options; however, hyperscale providers rarely, if ever, talk about something that is very important. Long-term strategies of portability and interoperability.
This paper will take a high-level look at what it means to lift-and-shift or to transform your environment, the impetus to move, the factors in moving, things to be aware of, also some topics you should be clear on when making the decisions. We’ll look at some of the simple economics of moving your world into the ethereal datacenter of “the cloud”, as well as the long-term effects of not following through.
Difference between Lift-and-Shift and Transform
Lift-and-Shift aka Re-Platform
To “lift-and-shift” or Re-platform is akin to moving from your outdated and crowded datacenter that has challenges around increased power and environmental needs and old communications options, by unplugging your systems and loading them into the back of a truck, driving them to the new, bigger datacenter and plugging them back in. You now feel you have room for growth, and (hopefully) the cost for the floor space is reduced, which is saving you money. With the new datacenter you can take advantage of ‘green energy’, and better internet access because of the new switches. Access to updated technology in the DC helps to drive costs down, it can also improve efficiencies for your business and customers.
The ‘modern’ version of “lift-and-shift” would be to recreate your current computing needs in a new location be it a different physical floor space you acquired or a different infrastructure model such as a new hypervisor, hyperscale provider or hybrid environment, then replicate the entire server “state” to that new location or infrastructure. Using Vendor tools, specific to your provider, or third-party tools like OpenText Migrate to move Windows and Linux servers from, or to, any ‘provider’ would replace the truck in this scenario. You would still need to “box” everything up for the move through an inventory process of what you have, arrange for “space” in the new location to move it too, verify it is accessible and accomplishes your needs. The “truck” would only be the transport mechanism.
Transform aka Refactor
To transform or refactor can have several meanings, but the result is a decision to change the way you use technology for your business and should provide for your strategic needs such as options for growth, or adapting to changing business needs, or optimizing costs, or a combination of any or all these goals and a lot more.
To “transform” or “refactor” generally refers to hyperscale providers. However, many may consider moving from a MS Access database on a Windows Server to a SQL database in SQL Server as a transformation. Moving from an old JD Edwards to SAP HANA is also considered a transformation. Moving from VMWare running an old JDE on a SQL Server VM to Azure SQL with Azure Functions Services deployed across a Kubernetes service that utilizes Web App and Container Apps, well that is a fully refactored transformation.
Impetus to move (Justify the Business Disruption)
Why Move
The first question to be answered is why move. What is the motivation to disrupt the current business computing environment? Is it the growing datacenter costs that are forcing the disruption? Is it a hardware refresh spend that is disrupting your planned growth or profit? Do you believe you can reduce risk once the disruption is completed? Is your company going through a merger or acquisition and you need to disrupt the business to eliminate redundancies or legacy technology? Is your application or operating system reaching an end-of-life event that is forcing this disruption? Does the new CTO or CIO want to put his or her signature on a solution? This last one is more common than you would think.
Lift-and-Shift, Rehost
Most actions that force a choice to lift-and-shift or rehost should be considered a disruptive event that needs dedicated focus. Moving the file and print server to “the cloud” is not a disruptive event, it can be a natural progression of the file and print service. Deciding to move your hosted CRM to an on-prem Hyper Converged Infrastructure (HCI) solution, or to move a newly acquired companies business solution from its current “cloud” instance to your “cloud” instance is a very disruptive event that can have catastrophic outcomes if not done correctly.
Transform, Refactor
All actions to transform or refactor are disruptive and need to have a clearly defined long term objective. As described above, to transform or refactor is a change to the way your business uses technology. You are no longer looking for the tool to provide the reports faster, or change the format of the customer invoice, or simplify inventory controls of your warehouse. Even a “simple” conversion to a new database is disruptive to the business if no defined objectives are made. Was the disruption done to save maintenance costs? Will that change support the expected growth of the database in the long run, or will you spend more because the costs increase as the ‘tier use’ increases?
Why Move to the Cloud
Any decision to move to a hyperscale solution should have a very compelling driver. You are not just switching hypervisors; you are adopting a new framework for how your business uses technology. Even though the different hyperscale providers talk about the same cloud benefits, how you implement and use them can be very different. So, you need to make sure the “why” is fully vetted and agreed to before you work on the next actions.
If the ‘Why’ is all about saving money on datacenter costs alone, you should be aware that those costs are just pushed down the road. Long Term cloud use without cloud integration is the most expensive use of cloud services. File Systems, ingress and egress charges, fixed resource costs, performance-based resource, DR zones for availability and a lot more expenses go into the long-term use of cloud services without a transformational refactoring effort.
The ‘Why’ for cloud decisions should include a strategic view of the corporate goals and a path with define stages and goals to get there.
If the ‘Why’ is to provide a new platform for technology use that is aligned with the long-term corporate strategies that may require technical responsiveness to optimize costs while keeping up with rapid developments in market strategies and business objectives, then the hyperscale marketing efforts are paying off.
Yes, it is true that if you transform and refactor the way your business currently uses technology into the hyperscale providers vision of tomorrow by using micro-services and stateless containers that consume resources as a service (meaning when they are needed) you can optimize your expenses on the technology while maintaining a flexible path to new technology features, such as AI, as they arise. But that also means you’re continually buying technology and may be locked into that technology path. How do you get to that ideal model of stateless micro-services? How much will that cost and when will you see the return on that investment. Current technology spend plus transformation costs should have a positive ROI in an acceptable time frame before you need to ‘re-invest’ in the next twist of tech.
Discussion On-prem vs Cloud
On prem solutions costs are usually all or nothing license prices. For example, it’s hard to buy an on-prem server with 16 processors but only pay for the ones being used at the time they are being used. You paid for 16 regardless of how many are being used. Same with memory and disk. If your industry has DR and Recovery Requirements then your costs can be significantly increased just on bandwidth and footprint, not to mention the costs to prove your DR site is accessible in a defined amount of time.
The Hyperscale providers include the ability to limit costs to what you are using with an option to expand use to what is needed at the time with a ‘burst mode’ concept. Azure calls them Scale Sets, Managed Instances for GCP and Auto-scaling Groups for AWS. Many of the Hypervisors, Hyperconverged and Hybrid solutions have this ability as well, but it may be a little more manual through Ansible Playbooks, instance or resource pools and scale plans.
You can purchase storage based on performance, ingress, and egress pricing. It’s very cheap to put stuff into cold storage in the cloud, but when you need to retrieve the data, it can get expensive. So, you are very selective when retrieving an archive out of cold storage. You can define a process that purges your database automatically into warm and cold storage. This way your hot storage costs are optimized, and unmanaged database growth is kept at bay.
Additionally, you can create a cloud environment that spins up containers as users, groups or regions need them. When the US East is starting up, EMEA is winding down and APAC has been off-line. With hyperscale solutions, this can be built into your cost model to optimize your total spend on hyperscale providers.
Reasons to Move:
- Immediate cost reduction options
- Optimized future technology costs
- Employ flexible solutions that allow configurable options for different clients (multi-tenant)
- Reduce hardware requirements with Web Client access (Phones, tablets, laptops)
- Adoption of stateless containers and micro-services to eliminate “OS license cost” requirements
- Rapidly deploy solutions into new or changing markets
What to move
Once the “why” is defined, you would think your next logical question is “how”. This is a loaded question. Every technology expert can provide an answer to how to move to “the cloud”, but that is like deciding to go to the store without knowing what for. Would you go to the big box home improvement store for the ingredients to make Lasagna? Would you go to the candle store to buy a new lawn mower? To be honest, the how is probably one of the last questions.
The “W’s” all take precedence over the “H”. Why, What, Where and When all precede the How for both Rehost and Refactor.
We covered the high-level points for the “Why” part above. You know your business cycles, demands and abilities to handle disruption, so you determine the level of detail on “Why”. With those details we need to talk about the “What”.
What to move is an open-ended question. The initial answer is usually “everything”, but does that really include everything? Walk through your inventory of applications and environments to determine what the “What” is. Then go through a sanity check loop for each:
What does this app or environment:
- Do for the business
- Cost the business (monthly, quarterly, annually)?
- Bring to the business in revenue and value
- Interact with to do its business
- Have for stated service level agreements
- Need for Availability or DR
For each application you need to know what the peak and idle values are for, Write, Reads and Delete, CPU utilization, Memory utilization. Also, does the peak/idle values change at month, quarter, or year end?
I’m sure you can add a few more checks for your specific needs but the goal here is to make sure you can clearly state the application demands from the technology and how it adds value to the business. Look at tools to create affinity maps and that collect and analyze the metrics.
This end-to-end analysis of the applications in your environments will be used to answer the next set of questions, but this is a long play. Keep collecting and measuring this information. Build a practice around it so you know what to measure against when you do finally move.
Where to move
Where to move is a business decision that many often think about as a singular item. Should I move to the cloud? Should I move to a managed service? The where should be dictated on the need not the destination. If you’re a regional trucking company your needs will be different than a national distribution company. If you are working in a medium size injury law firm, your requirements for “Where” are different than a global Business and Contract law. There is no single “Where” that fits everyone or everything. Even a small grocery store group would have a need to utilize cloud services, on-prem servers and even a managed solution for some business needs.
All Hyperscale provider support a 'refactored' solution. Those solutions are custom created to utilize the services and resources of that specific hyperscale solution. However, you may also need to maintain a critical environment on premise to provide for regulatory, security or performance needs.
If you use a service bureau for arbitrage, product delivery, shipping, service delivery, banking, contracts, payroll, security, or many other business use cases, then you will need to understand how they interface with the “Where” you are looking to move to.
Some critical things to note. After you decide the “Where”, you still require in-house technical skills to manage the IT infrastructure needed to access it. On premise routers, switches, communications, and networking don’t go away. You still need to provide local device support, printing, scanning and lots more. Your big footprint may move, but you still have a local footprint to maintain.
Summary of Where to Move
As you can see, your choices of where to move is as critical as the decision on why to move. Once you complete your analysis, I bet you will find that different Lines of Business (LOB) in your company will have different “Where” needs. Critical, time sensitive requirements may need on site compute resources where a CRM or HR package may work best in different cloud solutions. If designed and built out correctly the management of a distributed resource consumption model can be easily accomplished and affordable, while offering very flexible growth options. But now you need to decide When and How to get there.
When to move
So, you did your analysis on Why, What and Where to move. You are now looking at When to move. If you’re like most mid to enterprise businesses, you realize that there is no one solution that fits all your needs. You also identified that each provider has options that can fit your multi-solution resource requirements. You pulled your team together, utilized consultants and subject matter experts and have put a business plan together, but you are missing one thing. When should you embark on this epic journey into your technology future?
The scary project
I hope this will help. The answer is NOW, but with a plan. You have several migration and transformation projects to start working on so you should start now but the real key is not to look as this as several different efforts with similar goals but one cohesive project with different milestones. You can start the refactor phase of the project while working on the Rehost phase. Changing your current applications into a microservice, containerized, multi-tenant solution while moving the current workload to the destination of choice can happen in parallel and drive the overall costs for the project down. As mentioned above in the Intro, the long-term costs of not following through often causes re-host projects to be considered less then successful. Moving to the cloud without a refactor will be more expensive in the long term due to resource costs, however the first year in the cloud can drive huge costs savings. These savings should be poured into the refactoring efforts.
Build out a plan to refactor your application with part of that plan a re-host into the hyperscale provider. Getting into the hyperscale solution sooner can help to work through operating costs, expose the teams to the hyperscale methods and requirements and save money in the near term that can be applied to the refactor efforts. In addition, if you have needs to re-host into an onsite Hypervisor, hyperconverged, or hybrid solution, then re-hosting in parallel will enable the teams to work through connectivity and performance requirements sooner.
How to move
And now to the “How”. Each of the cloud providers offer their tools for re-hosting or refactoring into their solution. Many of the refactor demands are provided by third party solutions already in the providers cloud, or in their own hyperscale solution. The “How” for refactor is a very large question that will not be addressed here, with one exception. If you are refactoring, understand that your use of technology in business will change. Ensure your refactor choice provides for future needs and flexibility. A long-term strategy of portability and interoperability needs to be included in the refactor. Will the adoption of the refactored solution lock you into a specific path or can that solution be supported in multiple technology options for future benefits? If utilizing a third-party solution, can you move to a different technology such as an HCI solution to Hyperscale option.
Re-Host
The “How” on Re-host is a similar concept as above. Each provider has their solution to move you into their platform. Most have adopted a modern concept of replication with minimal impact to the business. Many providers will state that their re-hosting service is free, which is true for a specified number of days, but like the concepts above, will this tool lock you into the specific technology? Is it a single use tool for that specific service without the ability to give you options? Not all re-hosting tools are the same. What if your business decision is to utilize a hyperscale provider for your sales management tool, but they are utilizing a Hyperconverged solution for global collaboration needs and a different hyperscale provider for their hypervisor growth? Can your re-hosting solution provide support for all of them, or will you need to utilize multiple tools to accomplish the same goal?
Managing Costs
The costs of a re-host and refactor project may be challenging. Managing the costs should be a key consideration for decisions on the “How”. There is a very good chance that during your “What” stage, it was identified that you have a lot of servers that are over or under provisioned. In addition, you probably recognize that you have experienced a case of server sprawl. Your refactoring efforts will directly address this by changing from Servers to Services, and from fixed resources that are over provisioned for peak use time, to utilized resources costs that grow and shrink based on current needs. However, these values won’t be recognized until you have refactored, unless you re-host with a plan.
Utilizing a third-party tool like OpenText Migrate to provide options on re-hosting can address both fixed costs as well as server sprawl. Allowing to consolidate or distribute workloads based on file and folder options can drive immediate utilization and operating costs down. Selecting multiple target destinations within the same defined processes will optimize the re-host as well as improve value and reduce risk.
OpenText Migrate may have a licensing cost, but the potential savings through streamlined processes and reduce risk will provide enormous value and faster returns on the investment. The ability to migrate several instances of SQL Server licenses into a single license using the SQL Modernization workflows alone may be able to make up for the price of all the OpenText Migrate licenses used in the entire re-hosting project. Defining a process that moves static archive files, or logs that require long term storage into a lower cost storage solution, while sending the critical or performance sensitive data to high-performance storage destinations in the same workflow provides its own added value.
Creating a process, automated through PowerShell or REST APIs if you would like, to re-host multiple source infrastructures, including Physical servers, into multiple destinations, including Physical servers, significantly reduces the re-host project risk while optimizing the human resource costs. No need for multiple tool SMEs or management of costly configuration or replication servers to make multiple copies of the data before getting to the destination. No challenges or added costs for high-speed networks or bulky initial and final synch processes. OpenText Migrate addresses this through byte level replication that maintains synchronicity without “block synch” requirements. If you have communications issues during the re-hosting effort, OpenText Migrate provides a CRC Checksum remirror. This means, no need to get a new synch point. Only differences are re-synched while current changes are processed near real-time. This also means that you can pre-seed your destination to reduce the initial mirror times. OpenText Migrate has no distance, performance, or size limitations. Combine the pre-seed abilities with low bandwidth and high latency networks and even the remote offices in ‘challenging’ environments can be re-hosted.
With OpenText Migrate, you have options for auto-provisioning into select infrastructures as well. If you are taking advantage of VMWare on your chosen hyperscale provider, OpenText Migrate can work through a defined workflow that will automatically provision the target VM’s in that VMWare on the hyperscale providers environment. If you have chosen Azure Stack HCI, the same workflow automatically provisions the Windows environments in Azure Stack HCI. OpenText Migrate has auto-provisioning options for Azure, AWS and GCP hyperscale providers.
When creating optional automation scripts through PowerShell or using the REST APIs, the processes and workflows are identical for each of the destinations so there is no need to change the process between a Nutanix HCI destination and an Oracle Cloud solution. Creating a process to re-host multiple source infrastructure servers into a managed VMWare solution is the same as moving them into the Oracle Cloud VMWare solution. Security access in many provider tools limit the ability to re-host effectively. Managed solutions restrict access to a hypervisors host, disk sector size differences between source and destination storage, driver differences, BIOS formats and lots of other limiting factors can affect the platform provider tools. These items are not a limiting factor for OpenText Migrate.
While your re-host and refactor project is going, your technology team is still managing their day-to-day actions. These actions include provisioning new servers, decommissioning old servers, adding application, security, and OS patches, and moving servers around based on demands and needs. What actions will your re-host and refactor project need to account for while your source environments are changing? OpenText Migrate provides the ability to not impact the business of IT during the re-hosting efforts. In fact, introducing a tool like OpenText Migrate to your IT staff while the project is being built out can help to reduce the project risk while optimizing the overall IT costs through streamlined processes for moving workloads.
Conclusion
When looked at with this information, it is clear to see that it is not a choice of re-host or refactor but to re-host AND refactor. The analysis, when performed using why, what, where and when provides all the information needed for the how. Building out a single cohesive project that creates milestones and goals based on both re-host and refactor will also prove a long-term option for the portability and Interoperability for your adoption of technology for your business. Selecting the tools and services to assist with refactoring will be based on your business needs identified in the design phase, but the choice for re-hosting should be driven by the ability to be portable and interoperable. Adopting the correct tool and processes early can reduce overall risk while providing optimize costs savings in the near and long term.
