If you are managing storage environment in your organization at some point in time you get to the stage where you need to make some drastic changes in your storage environment. Amount of data companies are storing is increasing on a daily basis but storage capacity in itself is not always the driver (and should not be the driver to go to Tier1 storage). What is your data, how important is it to your business, how available does it have to be, how fast should it be accessed? These are just some of the reasons that may prompt you to look at different technology for storage than what you already have in place.
Storage industry in recent years started dividing types of storage you have in to Tiers. I will not go in to detail here on what these are, a simple search on the web will give you all the definitions you need. Briefly, lower the Tier number, for example 1, better the storage is. In here I wanted to share our experience when we were preparing and executing migration to our new and shiny Tier1 storage. To protect the innocent I will not mention any brand names here, what is important for us as a corporation is that we are now using storage systems that are based on Intel product. Nice!
Tier1 storage was required in our case because it provides best performance: throughput, uptime, reliability, scalability; for our all-important data. And subsequently it costs more than the old storage. The cost in itself is not necessarily related to any particular vendor; it is the fact that you are buying Tier1 storage that drives the price. Once the storage technology is identified next thing on the agenda is to sit down and figure out how to migrate existing data across to your new storage. This is where the fun begins.
Setting the technical challenges aside, if you want to sum up the biggest hurdle in the migration it is the stakeholder’s management. Technically your migration plan can be very simple, and in most cases are. There are tools out there provided by vendors that will allow you to move data from one storage to another with very little effort and overhead. Vendors will normally provide you with all the help you need and since you are paying the top dollar for these new systems you should use everything that is pushed your way. So on the technical side you are most likely sorted and can come up with solid plan fairly quickly.
The pain is when you need to figure out how you manage impact and how to align all the stakeholders. In the ideal world you would know exactly who your stakeholders are and in turn they would know exactly what needs to be done to contain their systems, communicate to all customers, health check, etc. Reality can be quite a different story. After having to go through one of these migrations recently here are some top tips on what to look out for:
- Start you planning early; outline all the steps and tasks with small team of your peers. Assumption here is that you are part of infrastructure team that will take care of storage/server/OS items.
- Identify all the support teams you may need - applications support, database support, network team, etc.
- Gather all support teams representatives and get them in to one room. Do not try and do any of this over email.
- Make sure you have actual names of people for specific applications or database systems you need to migrate. Most of the migrations would require brief downtime to switch over between storage systems so you need to know who is doing what.
- Communicate all your planned changes to everyone and anyone as much as you can. IT organisations would have some sort of change communication process in place - use it, do not cut corners on this one.
- Limit number of systems you are migrating in one go to a manageable number. Do not assume everything will go as planned. Trying to squeeze too many systems in to one slot where you are left without any time in case things go sideways is not a good idea. Things on occasion do not work as planned...
- Do not start your migrations if you do not have all the support teams you need. Do not assume because previous day everything went well and you have an idea on how to, for example, contain SQL on a server that you should do it without SQL support engineer.
- Stick to the plan and do not deviate.
- Make sure you have a peer installer for all tasks. Second pair of eyes is very helpful thing to have. Nothing worse than having to explain to your management that issue that caused the downtime was due to a human error and could have been prevented if you had one of your colleagues looking over your shoulder.
- Call out all the tasks and make sure they are completed as planned and with expected outcome. Document any issues so you can learn from them.
- Once all is done and dusted and successfully migrated - make sure you take the team out for some R&R. And if you cannot then at least recognise them in whatever option you have at your disposal within your organisation.
Above list came out a bit lengthy and when I started I honestly did not think it would be that long. I hope it will still be useful to someone who is embarking on similar project. I can think of other items that you would want to keep an eye on, but these are very specific to the technologies we used and may not apply to everyone.
Some of you may say what is so special about the above, it is common sense and it is basic stuff around project planning!? And it would be a fair assessment, however as we learned during this project going back to basics is the best thing you can do to ensure success of your project, especially one that involves touching pretty much every single system in your environment and involving many resources in your IT organisation.
So if you feel so inclined, it would be nice to hear what challenges you had when trying to switch to a completely different storage technology!? Or if you have any question for your future migration drop me a note and I will be happy to share what I know...