The Top 5 Don’ts of Data Center Consolidation

With corporate America driving down costs and expenses in every department on a year-by-year basis, it’s no wonder that data center consolidations are at the top of almost every IT agenda. Whether it’s due to past growth, acquisitions or delays in consolidating for various reasons, the benefits of taking a large number of isolated and segmented data centers and consolidating them into a much smaller number is quite staggering.

For example, even the President of the United States just recently signed a memorandum aimed at shrinking the federal government’s stock of data centers requiring agencies to work toward a target of US$3 billion in cost savings by 2015.

With that said, and from participating in many large data center consolidation projects on behalf of my clients, I’ve found it’s as important to know what not to do as it is what to do as you embark on this long-term initiative. Here’s my take on the top five Don’ts:

1) Don’t Believe the Cost Savings if It Is Projected Over 4 Years or More

Admittedly, this is probably true of anything in IT, but it’s even more important when the numbers are bigger because the errors within the saving estimates will be larger too. Closely associated, don’t believe that you can really get it done in the amount of time planned.

Again, errors made early will only manifest themselves over time — and you typically can’t do much to get that time back on a project as large as data center consolidation. So be prepared to willingly accept almost doubling the estimated time and achieving close to half of the estimated cost savings within that same justification that got your project funded in the first place. Sorry, but that’s just reality.

2) Don’t Underestimate the Impact on ‘Business as Usual’

Hopefully, you have some dedicated staff for your consolidation project. Well, drop the “hopefully” and insert “you’d better” have dedicated staff, because a data center consolidation project of any size requires the attention of a team whose sole responsibility is both driving tasks and continually working toward achieving the overall success of the project (smaller milestones work well).

However, here’s the issue: That dedicated team will be relying on other staff who still need to do their regular jobs. For starters, think server builds, storage configurations, purchasing, networking, and even the physical stuff like rack installs and cable runs. Then add in the fact that most migrations happen over nights and weekends. If you don’t add additional resources in those teams, then see the previous bullet.

3) Don’t Over-Plan

So you’re taking this seriously from a staffing, project plan, and funding perspective — good for you. What I’ve seen happen with too many clients at the initial stages of a consolidation project is over-planning.

That may sound strange coming from a consulting background, where we make fun of “ready, fire, aim” — but I’ve seen over-planning become the Achilles heel of these types of projects. Putting in too many controls and check-points, refining a process four or five times before ever executing it once and not taking advantage of refining from “lessons learned” as opposed to “customizing and tailoring alleged best practices” will result in delay after delay after delay.

4) Don’t Believe All the Tools in the World Will Make It Better … but Don’t Presume They’re All Over-Rated, Either

I’ve seen both sides of this spectrum, and neither is very pretty. Some clients are enamored with tools, using off-the-shelf, home-grown, and every custom script you can think of. The result: Duplicate data in multiple tools, multiple interfaces to try to get them all working together, daily customizations, and no formal support infrastructure for any of it. Nothing good comes of this, and it also increases the rate of error because the underlying data is no longer reliable. More often than not, it’s back to square one to remedy this situation.

Conversely, I’ve also seen some clients that think tools are over-rated and will stick to the comfort of Excel and Project to run the initiative. While these work well, using them alone to support a large-scale, specialized data center consolidation project usually fails miserably.

There is a middle ground here — think relational database, single source of data (I like to say “single point of truth”), and no more than one or two tools that know how to talk to each other, and are tailored and specialized to support data center consolidation initiatives.

5) Don’t Let the Business Units Run and Drive the Migrations

I know you’re thinking “the business runs IT, not vice versa,” but if you let the business units run and drive a data center consolidation project, then go back yet again to the first bullet.

The business units know a lot of things — their applications, their customers, the financials, etc. However, I’ve yet to run into a business unit that knows data center consolidations. So IT needs to drive while working closely, and even partnering with the business units to ensure success. IT can’t (and shouldn’t) map application inter-dependencies, but they can ensure all the base infrastructure, data migration methodologies, and supporting IT infrastructure is there, rock-solid, and ready for those migrating applications.

Keeping this article to just the top five was pretty difficult, as the overall check-list of what not to do is long. And even making these the “top” five could be a stretch as well — I could go on and on about how important application interdependency mapping, grouping applications into “packages,” and latency testing is key to success — that’s just one example. Hopefully though, this got you thinking about things to avoid if you’re embarking on a data center consolidation project of any scope — as avoiding the pitfalls before you hit them is half the battle.