6 Tips for a Successful Migration Program
For large enterprises undertaking a migration program, it can be a costly and challenging exercise. With no guarantees that you will arrive at a better end state compared to where you started. Whether it is uplifting legacy technology assets or planning data centre migrations to private or public cloud (or a hybrid) – Here are 6 tips to help plan a successful migration.
1. Start with the problem
Too often IT is guilty of coming up with a solution or technology under pressure of what is in vogue or what their peers are doing in the market. If your IT department is aligned to the business needs, then naturally the technology can be designed to better effectively support the business goals rather than the other way around. The goals maybe to better control costs, to support business growth (or downsizing), or to allow your enterprise applications to be accessible by authorised users, securely and anywhere.
If you are late to the party and/or still running legacy on bare metal, you will be limited on your options for migration and reduce orchestration and automation opportunities in this Dev/Ops driven world. Migrating from legacy can be a challenge (although most cloud providers offer Mainframe emulators), but is can be overcome by splitting the client piece (front end that your users interact with) and the back end (which is maybe harder to move or virtualise).
3. Where are we now?
It may seem crazy, but most medium to large organisations struggle to understand exactly what their IT environment currently looks like. Pick a server at random and ask the SME what team/project is using that and why and you may get a blank stare. Knowledge is often maintained in spreadsheets and emails and often only true as of a point in time. Effective planning of your migration requires a deep appreciation of your current IT fabric & the underlying relationships. How does an individual DB server relate to a business process and what is the impact of change on this server to the wider business and who are the stakeholders? Does this business process traverse multiple interdependent systems? Understanding your current IT fabric is a foundation for a successful migration program.
4. Where are we going?
Armed with knowledge of where you currently are, you can begin to plan a future state based on your business goals. This may lead to an end state of hybrid public and private cloud. With the vision in place you can now start to slice the migration into sprints of activity. One strategy is to focus on lower environments one at a time, i.e. look at your lower environment for a system ‘System x DEV Instance’. Decide whether this is a ‘lift and shift’ (if possible) or a ‘build new and decommission old’. A migration program is a great opportunity to identify and permanently decommission unused/idle systems and start reducing your future OPEX.
5. Orchestrate and Automate
Each critical manual step to decommission and spin up a new server should be a target for automation. Each of these sprints of activity will feed lessons learned and areas for automation to be included in the next sprint. The theory being that once you get to migrating the critical production instance, you have a tried and tested repeatable set of steps which are automated to minimize human error. These scripts can then be reused as a part of your auto scaling strategy to build resources when there is increased demand.
6. Align technology costs with the business
A migration is a great opportunity to start fresh and begin understanding exactly who is using what and understanding the associated cost with providing the service. This does not necessarily mean introducing a clunky charge back model, but there is tremendous power in presenting dollar figures to the business team for the cost of providing the IT service. Most reasonable business units will not object to paying for the things they use, after all, if you have gotten the first point correct and aligned IT to the business need, then more IT cost will equate to the business doing well. On the flip side, the business will be quite vocal in ensuring that they are not paying for the things they do not use. e.g. If there is an end to end environment sitting idle for 90% of the time, then let’s make sure it is only active for the 10% of the time. This helps minimise waste improving the value as well as acting as a permanent sanity check on whether IT is aligned to the business.
More information on leveraging ‘EcoSystem Migration Center’ to plan, model and execute a migration program can be found here. If you would like to talk to one of our solution consultants to discuss in more detail, please reach out to us on our contact page.
Do you ever wonder why the environment preparation or releases take so long? After all, the company just invested “zillions” on a whole bunch of great tools and a cloud framework.
So, you have decided you’re going to implement a Scaled Agile Framework (SAFe) and promote a continuous delivery pipeline by implementing “Agile Release Trains”…
It goes without saying, that the backbone of all organizations today is digital and independent of the end-products you provide, there is an inherent need to drive your features and solutions from conception to production…
I am continually ‘un-amazed’ when I go into large organizations and look at their ‘DevOps’ strategy. At a team level, it’s invariably no different to what we were doing back in the late 90’s…
The intention of environment synthetics is to provide ‘high-level of confidence’ applications (your system instances e.g. UAT Home Loan System) and their underlying component services…
DevOps & DevOps at Scale is little a bit like comparing the building of Sand Castles on a Beach to Town Planning. Here are 5 practices to promote as a way of preparing for a DevOps at scale capability…