Ryfujk

Other answers cover the technical aspects of the move. You may also have to consider some other things.

Make sure users know that their applications will be down during the move. You will want to schedule the move, perhaps during non-working hours, so that you minimize the number of people affected.

Have a knowledgeable person (or persons) test the applications after you bring up the servers. Have them do some sanity checks to make sure the applications work as expected.

After the testing, tell your users that the move is finished and have them let you know if they have any problems.

It's quite difficult to tell and borderline "too broad" for our format. The most important thing you need to check is if you need to reconfigure your network in any way of if they can keep running with the same addresses. Even if they can keep the same addresses, make sure they are not configured via DHCP and/or verify the DHCP server will be available at the new location.

Side note: As you already stated, having the SQL server and it's mirror is far from ideal. However, having the backup drives at the same location is really dangerous. You need to have your backup in a different physical location.

Other answers have good pre-move considerations. However, you should also be planning how you organize the actual move. From the fact that Machine3 is a mirror of Machine2, it looks like uptime is a significant consideration for the SQL Server 2008 R2 database(s). The fact that it is a mirror provides you with an opportunity. The reason for the existence of a mirror is to be available when the primary server is not. That includes not being available due to maintenance, which includes moving.

Make a plan:

You should make a written plan for how the move will be carried out. You may need to be able to provide this plan, or parts of it, to people handling portions of the work (e.g. the movers). This plan should include all pre-move activities, the actual move, and post-move actions (e.g. verification of functionality).

Move Basics:

1. Move Machine3 (the SQL Server mirror): Get it fully operational. Verify re-sync.


2. Move Machine2: Get it fully operational.


3. Move Machine1: Get it fully operational.

More detailed description of the move:

The following includes two methods (Path A and B) of using Machine3 to test the connections for Machine1 and/or Machine2. You should only use one method. What way to do so, or even if to use either, depends on information not contained in the question (e.g. physical separation of the final machine locations, physical size of the machines, length of network/power cords, availability of extensions for same, similarity of network port configurations, uptime needs, etc.). Using Machine3 to test these connections potentially allows higher uptime for Machine2, but particularly for Machine1, which has no mirror. You can choose to use either method, or neither.

1. 
   

   Move Machine3 first.

   
   
   
   
   
   • Leave Machine1 and Machine2 in place for now.
   
   
   • Backup Machine3, then shut it down
   
   
   • Get Machine3 completely moved to the new location.
   
   
   • [Path B: Not used if you are going to use optional step #2.] If the network and power configurations for all machines are identical: Put Machine3 where Machine1 is planned to end up using the connections intended for Machine1.
   
   
   • Get Machine3 back up and running. In the new location, verify that it is functioning normally as a mirror of Machine2. This will provide physical verification that the configuration of all issues (power, network, etc) are functional in the new location.
   
   
   • Resolve any issues which come up.
   
   
   • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.
   
   
   
   


2. 
   

   Path A: (Optional):

   
   
   
   
   
   • Use Machine3 to test all facilities intended for Machine2 and Machine1.
   
   
   • Shut Machine3 down and move/switch to using the position/connections for Machine2, (verify re-sync) then Machine1 (verify re-sync). If you planned to do this, then Machine3 should have initially been set up with the connections intended for end use by Machine1 or Machine2, so you to not set it up first in the end location for Machine3 and then change it 3 times, but only 2 by starting with it using the facilities of one of the other machines.
   
   
   • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.
   
   
   
   


3. 
   

   Move Machine2.

   
   
   
   
   
   • Your practice with Machine3 should make this much smoother.
   
   
   • Backup Machine2, then shut it down
   
   
   • Move Machine2 to the new location; make all connections
   
   
   • Resolve any issues which come up.
   
   
   • Verify that Machine2 has fully re-synchronized with Machine3 prior to proceeding.
   
   
   
   


4. 
   

   [Path B: Not needed if you tested all connections with Machine3 in optional step #2] If now have Machine3 where Machine1 is to end up:

   
   
   
   
   
   • Shut down Machine3.
   
   
   • Move it to where it is planned to end up (out of the location you intend Machine1 to be located).
   
   
   • Resolve any issues which come up.
   
   
   • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.
   
   
   
   


5. 
   

   Move Machine1.

   
   
   
   
   
   • Having moved Both Machine2 and Machine3 (and hopefully tested the actual connections Machine1 will be using by having Machine3 use them temporarily), this should be the smoothest of the moves.
   
   
   • Backup Machine1, then shut it down
   
   
   • Move Machine1 to the new location; make all connections
   
   
   • Resolve any issues which come up.
   
   
   • If something goes wrong with the facilities in the position that Machine1 is supposed to occupy, you have the option of using the facilities where Machine3 is now located. Hopefully you were already able to test all facilities in the Machine1 position by having it already used by Machine3 for a time (Path A or Path B).
   
   
   
   

If any of the servers' IPs will change then and connections are made to the SQL box via DNS resolution then you will need to schedule a change to the DNS records at the same time as the move.

Things you should know about the intranet software and databases:

• Does the intranet software connect to the SQL Server via IP, NetBIOS, or DNS?


• Do the SQL Server user accounts used by the intranet software have authentication limited to traffic coming from an IP?


• Do employees at your company access the SQL Server directly from any spreadsheets or reporting tools, if so, how do they define the DSN?

If you don't get the exact same IPs, or if you end up on a different sub net, you will need access to change the source code or configuration files for any apps that connect to the SQL server. People could be relying on undocumented and direct SQL access for ad-hoc reporting.

Utilize your "Disaster Recovery" servers. Switch over to them to handle the load while you move your production servers. With properly configured DR equipment you can do the move in the middle of the day without seeing much downtime (up to 15 mins). As the disaster recovery servers should be configured in the same manner as the production servers. If you don't have DR equipment, I highly recommend getting them.

Think of it this way: while your corvette is getting a tune up, use your minivan to get through the day.

One thing I don't think has been mentioned is physical security of the new home of the servers. What was the room used for before and who has keys to it? Is there adequate security (alarm systems, cameras, etc.).

Some considerations in addition to the other answers:

• Are the applications linked to other ones by e. g. nightly exchange of data by file or by use of webservices? What are the consequences when the applications are not available? Can related applications cope with this or do they fail or even produce wrong results due to lack of information from your applications?




• Is a downtime acceptable for your users, company or even clients? How long may it be?




• I think it is a good idea to have a plan for a rollback. You can use it in case of a problem that can't be resolved quickly, e. g. a network problem. You will probably need to keep the mover available for the case of bringing the hardware back.




• Do your applications lead to high network traffic and does the network have to be prepared for this (probably much more unlikely a problem than issues with addresses and firewalls)? If you have real time applications (e. g. video conference software) latencies will be important.




• The servers must fit into the server rack if you have one.

IT Relocation Planning 101: Everything You Need to Know

If you need help with your IT relocation planning then you're in the right place. Check out this handy guide to find out everything you need to know! The same goes for moving your data. If your business stores sensitive or confidential information on hard drives, you'll need to pay attention. There's a high risk of compromising your data if you don't have a solid IT relocation plan and checklist in place. We'll tell you everything you need to know about IT relocation and relocation planning.

No to Trash

Hard drive shredding is a safe alternative to simply throwing hard drives away. By throwing hard drives in the garbage, anyone could end up with your confidential business information. Shredding ensures that old hard drives are totally destroyed. It makes it impossible for anyone to access the information stored on the drives. This is one of the key aspects when it comes to IT relocation. Along with this, the environmental impact of simply trashing old equipment is a serious ethical issue. We will discuss this further along in the article.

Relocation Planning

It's recommended that the entire IT relocation process is overseen by a project manager or project management team. The addition of a design plan outlines the details from your current situation to the end of the process. It covers everything from where you are in the process to where you want to be. In addition, an implementation plan will outline all responsible parties, steps, and dates for tasks. This ensures the various steps happen in proper sequence. Remember, it's never too early to start planning. It's critical that the move-day plan is set out well in advance. This will summarize the activities on the day of the move, to ensure all run smoothly. In order for all these plans to actually work, it's useful to have someone appointed as Project Manager. They should oversee good communication between different role players, as a single point of contact. The Project Manager will be central to managing the IT relocation checklist, which is a key element of a successful migration.

Briefing and Budget

As part of an IT relocation plan, it's useful to address potential risks. Contingency plans should be in place and all role players should be ready to fulfill their duties on the day. Any partners involved should get an extensive briefing about what to expect. Prior to the moving day, partners should be reminded of their responsibilities. This information forms part of a project plan. It should include the budget, resources, and the IT relocation timeline. As you can see, a critical aspect of this move is good, well-executed planning. To avoid miscommunication, specific areas should be documented in detail. These documents are a central part of the process, as they outline agreements, inventory lists, and diagrams.

Minimize Downtime

Data Relocation is a costly and time-consuming project. It's also potentially high-risk and needs to be done with careful consideration. An important question people have regarding IT relocation is about the time it will take. 'How this will affect my business?' they ask. A major risk of data relocation is the downtime associated with it. Downtime can be very costly, which is why you want to minimize or even avoid it if possible. For this reason, your IT relocation must be planned and managed with expertise. Extensive planning is key to minimizing downtime and saving you money. Proper planning can take months. If your company lacks expertise and is unable to form a solid data relocation plan, find a partner who can assist with this. Taking on a data relocation process without adequate planning and resources can be dangerous for everyone involved. It can cost your business downtime, data loss, and serious security risks.

Inventory Importance

One of the first steps in an adequate data relocation plan is to compile an equipment inventory list. This relocating list involves a thorough site audit and a review of the current resources. After this, you'll be more aware of the critical elements that'll need to be moved first. Along with this, you can make decisions about what items need to be replaced or upgraded. It's recommended to hire data center experts who can audit your site in detail. They'll assist you in your decision to either replace, upgrade, or decommission your current machines. This will help you to understand your current infrastructure network and equipment. In addition to the hardware, you'll also need a specific listing of your applications and software licenses. This sounds like a lot of work. And it is. But it's critical in helping you design your migration strategy. It'll guide a list of workloads and the sequence of migration.

Big Bang Theory

After you've decided what equipment you're moving and what you're replacing, you must decide whether it'll be moved all at once. This is known as a "Big Bang" approach. The alternative is to move in phases. Relocating in phases may reduce downtime in the long-run. It'll allow your business to get parts of the data center in working order before everything else is moved. If you're back up and running, you can continue with operations. However, please note that these relocations are very risky and complex. If one part of your system malfunctions before being re-installed, your entire system may be down for a while. If minimizing downtime is a priority, you can look at a "Swing Gate" approach that recreates your data center at its new location. It's a temporary recreation and will keep your system running during the move.

Support System

Keep in mind that your business may have to hire an expert to assist with your data relocation needs. Even if your company is equipped with the necessary skills and talent, some equipment migrations are very complex. In this case, you run the risk of depleting too many internal resources. If your team is focused on the migration, their time will be taken away from their usual tasks. Other equally important projects may be overlooked leading to serious consequences. Always take into account all aspects of the move. Coordinating transport, managing chain of custody, insurance coverage, and logistics costs are just some of the aspects to remember. Due to these varied tasks and requirements, it's almost always better to look for a support system. Especially if the move requires specialized help. Ensure you select a team with varied experience. If they can assist with the entire project, you are ensured higher levels of safety and proficiency from them.

Document and Test the Migration

Remember, it's critical to document the whole data migration process. All equipment that is moving should be tagged. The warranty and serial number of each piece must be checked in order to avoid the warranty expiring during the move. In addition, remember to make a new office checklist with all requirements for the new space. Don't forget, some equipment will require specific licensing in order to run concurrently while you relocate to the new space. Disaster recovery plans must be in place. Test these, too, before the actual migration. As soon as everything is installed in the new place, start testing. Check the machines and equipment against the inventory. Ensure nothing was lost or broken. After this, you should begin testing the systems and applications. Ensure they're all up and operating correctly. Before the move, you should devise a post-relocation restart and testing plan. It's critical to ensure everything is operating correctly before going live.

Freshen Up

The post move clean up is the final critical element in your relocation. You're ready for your fresh new start. But first, there's still a few final tasks to take into account. Firstly, review your punch list to ensure everything is done. Next, ensure you have good quality documentation of all relocated items. Then, you may need to liquidate assets that are no longer needed. And finally, it's important to dispose of and recycle base materials. An IT relocation will often involve the disposal of older equipment. This includes packaging materials, copper from cabling, and extra metals. All of these have serious potential implications of the environment.

Data Relocation Service

In order to truly optimize the efficiency of your relocation and minimize environmental impact, you may want to work with a data center relocation service. They'll offer a recycling program to ensure a quick transition and an environmentally friendly migration. As you can see, there are many elements to keep in mind when dealing with IT relocation planning. The key aspects are starting with a solid plan, seeking support, and documenting every step during the process. Please contact us to find out more about a suitable relocation plan for your business needs like NCWS.