IT Tips & Tricks

Published 5 August 2021

The Animals Went In, Two by Two, but Your Data’s Lost, So What Do You Do?

How do you keep the hounds of hell from your door if a data migration goes horribly, terribly wrong?

When a migration goes wrong, you can attempt to hide from the boss at the office, or, if you’re working from home, you can pretend that your phone is dead or your internet connection is down. Avoidance, however, is not only stressful, it’s also only effective in the short term. Ask any ostrich. When frightened, they lower their heads to the ground in an effort to avoid being seen by a predator, perhaps believing that if they can’t see the predator, the predator can’t see them. For a bird that can reach a height of up to nine feet, that’s pretty dumb. Other than showy feathers, just about the only thing ostriches have going for themselves is the fact that they can run like hell. But us? We have to face the music, even though we wish by all that is holy, that, like the ostrich, we could run 45 mph, with bursts of up to 60, disappearing into the sunset, never to hear the words “migration” or “missing data” ever again, as long as we live.

Unless you have plans to either quit the IT industry or creep aboard ship as a stowaway bound for distant shores, that’s not likely. So, we’re going to take the bull by the horns and discuss data migrations, with a special focus on data that goes missing and one of the most common causes of that.

Data migrations. They’ve become something of a necessity in this digital landscape in which we live. Whether it’s due to the fact that more employees are working remotely, or that companies have realized that the money they’ve been spending on large, swanky office space isn’t really entirely necessary, the bottom line is that more and more data is being shifted to the Cloud or to hybrid systems, with some data in the Cloud and some hosted on-premises.

We know that while there are a multitude of problems that may befall any data migration, there are four real doozies that can seriously derail a migration project. We’ll offer solutions too, so don’t take off like a startled gazelle just yet. (What the heck is with all the animals in this piece? It’s like the Annual General Meeting of the residents of the Ark. Anyhoo, moving right along.)

Data is valuable and worth protecting. Don’t let it be a sitting duck.

Problem 1: Disorganization and the Confusion it Causes

Before you dismiss this as something that doesn’t sound like a technical issue, we’re going to ask that you stop and consider the fact that a large proportion of data migration problems can be traced back to a degree of confusion surrounding the actual migration plan, combined with a lack of adequate preparation for the migration itself. We all know that technology transfers can be massively complex undertakings these days. If the team members responsible for those moves omit to adequately inventory systems and data, or underestimate the time and effort the relocation will take, or fail to identify the resources that will be required in the new environment, what do you think is going to happen? It would be akin to the 1.5 million migratory wildebeest in Africa suddenly finding themselves utterly clueless as to where they were meant to be going. The result? It would be total chaos.

Solution 1:

How can something that sounds so simple turn into such a colossal pain in the backside?

We’ve said it before and we’ll say it again (probably repeatedly, for the rest of our natural lives). There are three magic words with which to kick-off any data migration: data migration plan. Seriously, developing a comprehensive, airtight data migration plan should be the very first step in any tech transfer project. Identify the scope and goals of the project, accurately estimate the timeline for its execution (or risk your own) and identify and assign the people who will be responsible for making it happen. Anticipate potential problem areas ahead of time and have plans for their solution to avoid your project getting derailed. In other words, smooth that migratory path for those wildebeest!

Problem 2: Compatibility Issues

“Hey, it’s no biggie. Just move the data and apps from here to there.” Yeah, right. How can something that sounds so simple turn into such a colossal pain in the backside? (By the way, speaking of colossal backsides, did you know that the blue whale has the biggest butt out of all ocean-dwellers, while on land, the elephant holds the “biggest backside” title?) Although some data may be relatively easy to lift and shift, it doesn’t automatically preclude compatibility issues further down the line (most commonly due to poor optimization).

Some files may become inaccessible when changing to a new operating system, as they’re no longer in a readable format. Another point to be aware of is the access controls, which may not make a smooth transition from the source environment to the new system, leaving users unable to access all the resources they need to do their jobs. (Cue the frustrated horde of disgruntled users bombarding your department with complaints and service tickets.) What would be the absolute worst-case scenario when it comes to compatibility issues? No doubt, that would be having the entire system crash once it’s removed from its legacy environment. Ugh. Our condolences if you’ve ever been in that situation.

There are times when a fly-by-the-seat-of-your-pants attitude works brilliantly, but a data migration is not one of them.

Solution 2

Earlier, we mentioned the importance of the data migration plan. An on-point, accurate data migration plan should include a rigorous assessment of the operational requirements of the current system, including how those requirements will need to be adapted for the new environment. Surely if a ten-ounce bird can migrate 7,500 miles, non-stop, in just 11 days (as does the bar-tailed godwit), we can get through a data migration without too much fuss. Sure, you can cross your fingers and invoke the protection of the IT gods all day long but migrating everything first and adopting a wait-and-see attitude regarding the compatibility issues that could arise later, is not the smartest way to go. Yes, there are times when a fly-by-the-seat-of-your-pants attitude works brilliantly, but a data migration is not one of them. All your system requirements should be well documented in advance and then closely monitored throughout the migration. And please, by all that is holy, don’t shut down your old operating system until the new system has been thoroughly tested and its performance validated. Honestly, in this arena, failing to plan is the equivalent of planning to fail.

Problem 3: Hardware Challenges

One of the most remarkable migrations in nature: The winged wonder of the world, the bar-tailed godwit, weighs in at a mere ten ounces and can fly 7,500 miles non-stop.

Software compatibility issues can be enough to drive one nuts (great for squirrels, but not for IT professionals), but equally important is consideration of the destination environment in terms of its ability to cope with the amount of data and applications being migrated. Sure, overestimating capacity can lead to unnecessary (and expensive) waste, but it can be similarly dangerous to assume that all assets will transfer to their new environment on a one-to-one basis. Differences in operating environments and the way different hardware deployments utilize resources can have a dramatic impact. And, as if that wasn’t enough to worry about, there’s always the “minor” technical detail of a server being damaged during transfer to a new location or optimistically arriving at the new location only to discover that your brand-spanking-new server cabinets won’t fit through the door. Face palm. Yes, it’s true. Sometimes, the Tasmanian devil is in the details.

Solution 3

Okay, we’re going to assume that you (or someone else on your team) were smart enough to bust out a tape measure and check the darn doorway, allowing you to actually get your new equipment where it needs to go. At this point, it’s important to make sure that it meets (or exceeds) the operational requirements of the data and apps that you’re about to migrate.

If you’re moving legacy hardware as part of your migration, it is critical that it is exhaustively checked after installation. Don’t fall into the trap of, “Oh, it’s been fine for X number of years, so it’ll be fine now.” Uh-uh. Moving legacy equipment can cause (unseen) damage, from things such as static discharge or dust and dirt breaking loose. It happens, it truly does, so it needs to be gone over with a fine-toothed comb after being moved.

Nobody wants their data to be a sitting duck during a migration.

Problem 4: Data Loss

Anytime you move a ton of data from one place to another, there’s always the risk that some of that data will get lost. Yes, some of it may be inconsequential, particularly if it’s junk data or non-essential data that genuinely won’t be missed. Then there’s the lost data that can be easily restored from your backup files. But certain types of data loss are much more serious. Quite apart from the potential disaster of losing confidential or private information that needs to be protected, data loss could also create a ripple effect that stops portions of the migration process. Yikes.

Imagine the chaos if 1.5 million wildebeest, each weighing up to 600 pounds, didn’t have a migration plan.

Finally, we arrive at the missing data due to broken file links. Depending on the scope of your migration, it’s not uncommon to have hundreds, or even millions, of broken file links following your migration. This leads to the aforementioned grumpy users, potential downtime and revenue loss, with your boss stalking about, looking like a bear with a sore you-know-what. Remember those 1.5 million migrating wildebeest? They lose one-sixth of their number during their trek. That’s about 17 percent. Who wants to lose that much data? Nobody, that’s who.

Solution 4

Backups, backups, backups. That’s the other mantra that we chant repeatedly around here, and with very good reason. No essential data should ever be moved out of its current environment without being backed up somewhere. Failure to do so can literally leave your data “over the rainbow,” which might be great for happy little bluebirds, but not so great for your data (or you, for that matter). Always ensure that IT personnel can rollback elements of the migration in case a problem occurs. In some cases, this could be done easily with backup images stored in an existing or off-site system. For mission-critical data that needs to remain available during the migration, swing or parallel environments can be set up to ensure business continuity.

For data loss that has occurred as a result of broken file links, you’ll need robust software like LinkFixer Advanced to rapidly solve (or, better yet, prevent) that issue. The beauty of this software is that you can use it before your migration so that you don’t end up with data loss due to broken file links in the first place. Or, if you’ve already completed your migration and have lost data that you need restored rapidly, LinkFixer Advanced can successfully be used, post migration, to rapidly repair those irksome broken links, ensuring that they point to exactly where they’re supposed to.

Truthfully, data is critical to the success of most organizations today. Nobody wants their data to be a sitting duck during a migration. If your data is important to you and your organization, surely it warrants all the protection you can muster?

For more information on LinkFixer Advanced, or to find out about the third way it can be used, please call 727-442-1822 to talk to a friendly Service Consultant or visit LinkTek.com where a no-credit-card-required complimentary trial version is available.

Remember those 1.5 million migrating wildebeest? They lose one-sixth of their number during their trek. That’s about 17 percent. Who wants to lose that much data? Nobody, that’s who.

Feel free to share this article on your social media: