Migration Dangers – The Missing Link(s)

Content Specialists like me frequently recommend moving large amounts of data from legacy systems to new systems, sometimes based in the Cloud, for cost-savings and updating/modernization. Some of my clients even change entire data frameworks just to enable “mobility” (Tablet and Phone) features, integral to new systems yet expensive to build-on to legacy systems.
One of the unspoken dangers of migration is the loss of data location values, or links. Each new system builds on a new architecture, with new data locations, tags, and meta data. This is wonderful for new information streaming into the new system, but a dangerous pitfall for older data, notes, and files that become “orphaned” in the new system. Most of the time the data remains, but the existing “pointers” are focused on the old location! Imagine if you move to a new home and all your mail continues to be routed to your old address!
If it is a relatively small amount of data, this is not a major disaster, and can be fixed on an “as you go” basis, by the user or an admin. The pitfall of this Is years later, when doing a recovery from an old backup or a revival of old cases – the problem resurfaces! If no one remembers what to do – Now you have a crisis, and spend time and money fixing something that you thought you already dealt with.
If you are fortunate enough to have someone like me on your project (or at least in your contacts) the problem can be solved with some basic but essential software, most of which is readily available, and can monitor your links for broken links and possible “404 – page not found” errors. These make even the most calm users shake their fists and pick up the phone to tech support, since they are “stuck” until the problem is resolved.
To recap, missing links occur when migrating, during routine backup/restore operations, and even when putting more storage on-line. If you are finding a lot of orphan links, give me a call.

ECM in the Cloud – The Migration

Experienced Technology Professionals have an acronym for moving content from one system to another called “GIGO” (translation: Garbage In, Garbage Out).

When we rush into a cloud implementation, with clear goals of monetary savings, faster time to production/delivery, and increased efficiencies, we need to remember that what we move to the cloud is as important as how we utilize it effectively.

The concept is that un-scrubbed data is guaranteed to be full of “ROT” (Redundant, Obsolete, or Trivial information).  You can classify this as the garbage I was referring to in my opening sentence.   It is always best to fix this information BEFORE you move it to cloud storage.  ROT will not fix itself.  It needs classification and attributes like ownership, retention and destruction dates.  If you do the “heavy lifting” of identifying your ROT prior to the migration, you get to manage it before it mystically grows to hundreds of Gigabytes or more.  You may even find quick solutions to eliminate ROT creation and create less ROT as the organizations data store grows.

Neglecting the abundance of older and unclassified information in a migration to the cloud would mean that “someone else”, at a later date, would inherit the wretched project of determining what information is classifiable and should be retained, and what to do with the rest.

Imagine if you move to a new home, and you pack up your clothes closet without checking to see if some of the items don’t need to move (don’t fit, never worn, stained, dated, ugly, etc.).  You are paying to move and re-hang garments that could be donated or tossed.  If you are moving to get more closet space, this can be awkward.  Data can be like clothes, and we all know how easy it is to order up some additional disk for all our content (like an infinitely expandable closet)!

Before you move all those items to your cloud storage, consider how bringing in a consultant can eliminate ROT, streamline your cloud migration, and save you money up-front, as you move items with policies, classification, and retention and destruction schedules.  I can help you create less mayhem in your cloud migration.