{"id":4143,"date":"2022-06-23T01:22:21","date_gmt":"2022-06-23T01:22:21","guid":{"rendered":"https:\/\/siteltd.co.uk\/?p=4143"},"modified":"2024-02-06T13:41:20","modified_gmt":"2024-02-06T13:41:20","slug":"data-centre-migrations","status":"publish","type":"post","link":"https:\/\/siteltd.co.uk\/blog\/data-centre-migrations\/","title":{"rendered":"Data Centre Migration – Challenges & Best Practices"},"content":{"rendered":"\n

Data centre migrations and computer equipment poses the largest risk in any implementation. While there is a common misconception that any Migration is simply moving data from Point A to Point B, the reality is almost always much more complicated.<\/p>\n\n\n\n

Gartner has recognised the risk inherent to Migration:\u00a0\u201cAnalysis of data centre migration projects over the years has shown that they meet with mixed results. While mission-critical to the success of the business initiatives they are meant to facilitate, lack of planning structure and attention to risks causes many migration efforts to fail.\u201d What exactly causes Data Migration to be so challenging?<\/p>\n\n\n\n

Common Data Centre Migration Challenges<\/h2>\n\n\n\n

Poorly understood & undocumented legacy computer systems<\/h3>\n\n\n\n

Every company\u2019s data landscape is unique. It may encompass everything from decades of old mainframes to homegrown one-off databases, each with its own level of support. Documentation may be non-existent, institutional knowledge may be limited, and key staff may be nearing retirement.<\/p>\n\n\n\n

Incorrect and\/or incomplete requirements that don\u2019t reflect reality<\/h3>\n\n\n\n

Data centre migration project requirements are often developed based on assumptions around the data, rather than actual fact. Mappings and translations based on assumptions may miss key values. Duplication between or across legacy data sources may not be expected or accounted for. Data structure disparity between legacy data sources and the new target system may not be fully understood.<\/p>\n\n\n\n

Poor quality & incomplete data<\/h3>\n\n\n\n

Your new system is only as good as the data underpinning it. Missing, invalid or inconsistent legacy computer data can cause ripple effects when it comes to the new system. While information may never be 100% clean, lack of attention to quality can cripple even the most straight forward projects, leading to last minute cleansing initiatives. How do you ensure that any gaps are filled and that you are not migrating too little (or too much)?<\/p>\n\n\n\n

Lack of attention to detail<\/h3>\n\n\n\n

It is very easy to overlook seemingly innocuous changes between source and target systems. Fields with the same name may mean different things, both within and across systems. A different field name may be used for the same purpose across systems or multiple values may have the same underlying meaning. Date and time formatting and field length differences can also easily be overlooked, with disastrous impact.<\/p>\n\n\n\n

Constant Changes<\/h3>\n\n\n\n

Other common data centre migration challenges include the propensity for continuous changes. Even the most thought through business requirements start to change once testing gets underway and the business sees how the new system performs. Changes can easily number in the hundreds and need to be applied and tested quickly to avoid putting the schedule at risk by delaying test cycles.<\/p>\n\n\n\n

Lack of a detailed test plan<\/h3>\n\n\n\n

Data centre migrations is a complex process, but comprehensive testing often takes a backseat to other concerns. Testing needs to be done throughout the project, and not just by the developers. The functional team and the business need to be engaged with testing to ensure that all requirements are properly met and that all rules are properly applied.<\/p>\n\n\n\n

Bypassing or delaying testing can allow corrupted information to sneak into the new system or result in Go Live delivered data which does not meet the needs of the business. Just because a record loaded doesn\u2019t mean its correct.<\/p>\n\n\n\n

Poor communication<\/h3>\n\n\n\n

Migration is generally part of a larger project and must coordinate reams of changes to complex technical requirements while also engaging the business functionally. Without strong IT and cross-functional team communication, unintended results are bound to occur.<\/p>\n\n\n\n

Data Centre Migration Best Practices<\/h2>\n\n\n\n

At some time the successful facility you rely on will run out of something \u2013 space, power, tolerance. When that happens you will be faced with the potential daunting task of data centre migration. If you talk to any IT manager the thought of any relocation of any equipment is a time of pure terror and frustration. For instance, the cabling engineers will all have a reason why they can\u2019t unplug anything. The end users have change window freezes and new application deployments that you can\u2019t alter.<\/p>\n\n\n\n

It just goes on as well as having to manage this while keeping within budget. Therefore, in many cases its best to step back and take a look at the good and the bad. Below is a checklist to ensure a successful data centre migration.<\/p>\n\n\n\n

Determine resource requirements<\/h3>\n\n\n\n

For a starting point, look at the current power demand per square foot and if at all possible increase it by 50% or 100%, depending on how close you are to the top of the current power availability. Density of processing and storage is raising the demand for power.<\/p>\n\n\n\n

If you err on the side of having too much available at the commercial entrance, you won\u2019t be sorry in the long run. In most cases, costs for establishing the power feed can be associated with the building cost and recurring charges will be for usage, which will be about the same regardless of the power size.<\/p>\n\n\n\n

Think about the layout<\/h3>\n\n\n\n

It is all white space, SANS, CRU\u2019s and PDU\u2019s; imagine how information will flow through the data centre. It comes in from the street via the network entrance. It goes back out via that same access. Firewalls, DMZ\u2019s, termination equipment should all be located closest to the network entrance with enough white space to allow for growth. Place the server storage assets where they are going to make the most sense.<\/p>\n\n\n\n

Don\u2019t accommodate everything in the first three rows of racks and then have an ad hoc implementation strategy. Even though the technology is changing fast, you aren\u2019t going to do a massive forklift upgrade within the next five years, so get the space planning done now. Plan for room to grow easily for your servers switches and storage.<\/p>\n\n\n\n

Cable the equipment once<\/h3>\n\n\n\n

That goes for electrical branch circuits as well as telecommunications cabling. Make sure that you have branch circuits pulled to all future cabinet locations. Dependent on budget companies purchase most of the future racks required and place them on the floor with branch circuits set but not actively ready for any data centre migration or relocation of equipment. The same goes for telecom cabling.<\/p>\n\n\n\n

Following on from the the second point, place your primary MDF in proximity to the network feed. Leave space for the core switches and enough space to allow for growth to capacity. The last thing you want is an invasive change five years down the road because you need to upgrade cabling or power. Pull fibre cabling to every cabinet. The incremental cost of the fibre cable is minimal and you already have the labour available to complete the installation. In sum, everything under the floor should be done up front.<\/p>\n\n\n\n

Get a clean business inventory<\/h3>\n\n\n\n

Nothing goes in the new room that isn\u2019t in the configuration management data base (CMDB) with an owner and notations about critical business process dependencies. Components need to have configurations as well as contacts, both internal and at the vendor. You cannot afford the, \u201cWe\u2019ll come back and do that later\u201d perspective.<\/p>\n\n\n\n

Get your migration processes in line up front by allocating delivery resources.<\/h3>\n\n\n\n

Use the (CMDB) to guide the migration of an existing data centre, and make sure every item in it has every field populated. Let your DC build out be the excuse for wiring into every aspect of the change process the maintenance of documentation in the system. Continuously update the floor layout information and keep notations about how you expect the growth to happen until it is at capacity. Don\u2019t let people have to assume what you meant to do.<\/p>\n\n\n\n

In Summary<\/h3>\n\n\n\n

These are what we believe are the Five Best Practice checklist areas that stem from a typical data centre migration. Taking advantage of them may not be easy for any migration. Success requires participation from a lot of groups within a company. A typical project can take 12-18 months from the decision to issue an RFP for space to the \u201cgo live\u201d date because other projects are going on during that time and may make support for your needs a lower priority. Build that support into your planning, but don\u2019t lose track of what you need for a successful migration.<\/p>\n","protected":false},"excerpt":{"rendered":"

Data centre migrations and computer equipment poses the largest risk in any implementation. While there is a common misconception that any Migration is simply moving data from Point A to Point B, the reality is almost always much more complicated. Gartner has recognised the risk inherent to Migration:\u00a0\u201cAnalysis of data centre migration projects over the […]<\/p>\n","protected":false},"author":4,"featured_media":4156,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[11],"tags":[],"acf":[],"_links":{"self":[{"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/posts\/4143"}],"collection":[{"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/comments?post=4143"}],"version-history":[{"count":4,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/posts\/4143\/revisions"}],"predecessor-version":[{"id":6308,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/posts\/4143\/revisions\/6308"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/media\/4156"}],"wp:attachment":[{"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/media?parent=4143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/categories?post=4143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/siteltd.co.uk\/wp-json\/wp\/v2\/tags?post=4143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}