6 ways to avoid the migration migraine

I started my career in a company that was specialized in data migration: the company I was working for specialized in migrations from flat file database systems to relational databases. Those were the days when we thought relational databases were the future of data management and data storage: soon, we’d be storing all our data in huge relational databases – or so we thought back then (http://www.orafaq.com/wiki/BLOB)… The NAS market boom still had to start and object storage was definitely not on our agenda.

But I’m diverting: the reason why I’m reminiscing about my data migration days is because of the how painful those migration projects were. The company I was working for was pretty good at what they did but in spite of that every project would be stressful at best, a nightmare more often than that. Think of debugging code that was written 20 years earlier (dead men’s code), missing standards, incompatibilities of all kinds … In short, I’m an advocate of architectures and systems that won’t require migrations – EVER!

Today, I find myself in a very different environment: structured data became unstructured data, gigabytes became petabytes and cloud, big data and IoT have made data more valuable than ever. The market is flooded with applications that enable companies to extract more value from their data. Tape archives are becoming less and less attractive – the disk storage market is booming. According to IDC, Worldwide enterprise storage systems revenue grew 7.2 percent year over year to $38 billion in 2014, good for just not 100 exabyte of capacity.

The big unknown for companies who are planning to deploy long-term storage systems is how much capacity they will need. Most storage managers know how much storage they need today and they may have a good idea of what their organization will need two years from now, but where will they be five years from now? Will data keep growing steadily or will new innovations generate even more data? Or less? So, how much storage should they be buying initially and how big should the acquired systems be able to scale? The answer is simple: you don’t know and to avoid having to migrate their data from one system to another at some point in the future, companies need to design architectures that will scale infinitely and will never require data migration. Here are the key requirements for such infrastructures:

Clearly, if you plan to never have to migrate your archive, the platform of choice needs to scale infinitely. This counts for total storage volume, but also for number of files/objects.

Make sure the system is hardware independent. This means the platform needs to be hardware agnostic (i.e. you don’t have to certify hardware so you can benefit from new hardware models as soon as they are available AND you can optimize operational servers with more memory, bigger disks etc.) and allow for a heterogeneous hardware infrastructure, which will allow you to gradually renew the hardware as needed.

Make sure you can upgrade, update and scale your architecture without downtime. This requires a complete separation of the software layer from the hardware. Especially for active archives at scale, you don’t want to have to take down your service for maintenance tasks.

Architecture flexibility: a free choice to deploy your architecture on one site or multiple sites and the ability to freely add more sites over time will guarantee that you can scale as needed or even gradually move data between sites without having to do an actual migration.

Not all the data in your archive is equally vital or needs the same access speed. A choice of data protection mechanisms enables you to optimize for availability, durability or cost-efficiency. Also, you may want to protect smaller data objects/files differently than large ones.

And finally, make sure your platform provides support for different data types and access protocols. This is especially important for archives that serve different workflows and workloads. Both Object and file access are desirable.


~ by tomleyden on May 26, 2015.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: