Phase 1 – Discovery

Anyone who knows about Data Centres understands something of the complexity of moving services to a new site. Usually this needs to be done in a hurry, with no service disruption and at minimum cost.

The drivers for data centre moves are:

* Mergers and Acquisitions
* Geographic Consolidation of Sites
* Building Moves
* Expansion

Like most things data centre moves can be done a number of ways:

* Randomly, hope for the best
* Server by server
* Application Instance by Application Instance

Having managed and initiated many data centre moves, I believe that I have the scars to talk authoritatively about how best to do them. The only way to maintain any control of the risk is to do an Application Instance move.

So what is an application instance? For each application we could have many instances, in most cases we will have Production, we may also have Development, UAT, Sandbox, Disaster Recovery etc.. Each of these is made up of Application Components, e.g. Oracle Database, Java Code, Webserver. So the lowest entity we can move will be an application instance component, e.g. the Webserver from the Production instance of Oracle Financials.

Why is moving by application instance the best way? Usually the biggest constraint that we have in the data centre world is getting development resources to step up and help us do the moves. By focussing on application instances we can minimize the time we need from these guys and remove a constraint. In addition we only have to worry about one set of upstream and downstream interfaces from these applications and one set of dependancies

In fact to execute a data centre move you can’t avoid creating and managing a CMDB (Configuration Management Data Base) throughout the exercise. There are lots of them about, HP, CA, IBM they all have capability in this space but none of them are really focussed on how to manage a data centre migration and the information and capability that you need to make it happen.

Many vendors will tell you that you can automatically populate the CMDB with discovered data and that it is easy to get the data right. That is just not true, getting a CMDB right needs focussed effort and much of it targeted at interviewing and collecting soft information from application development and the business. Discovery can be useful as a starting point but it needs lots of massaging and configuring to get it meaningful enough to manage a move. Glasshouse Technologies have a world class tool and methodology called Reflector that is specifically designed to manage large and complex data centre moves.

We need to understand what applications are in use and which business processes they support. We need to understand who provides technical and business support for these applications – this enables us to properly engage the right stakeholders.

We also need to understand the hardware and servers (different from hardware as this refers to LPAR, Domain, VMWare Container) that each application instance executes on.

So we have defined the first phase – Discovery of the current state.