The 7 deadly sins of archiving migration: # 7 – sloth
- November 13, 2015
In our experience, archiving vendors, especially those that sell proprietary systems, make it relatively easy to get large amounts of data into their systems, but pretty hard to get that same data out. Over time, however, those same archiving vendors have responded to customer requests by developing APIs or SDKs that enable archived data to be moved out of their systems.
As a company whose team grew up in the archiving world, we’ve watched with interest the attempts of other migration vendors to work with these vendor APIs. Our collective radar went off when we first heard migration vendors promoting the fact that they were “fully certified and are jointly working with the Archive Software Vendor to be fully supported and certified on their [the archiving vendor’s] systems… to insure we are migrating the data out of the archive in the approved manner as defined by the archiving vendor”. Our response to that is “so what?” Why would you need the vendor’s approval to move your data out of the software tool that you’ve purchased?
Here are two key points to consider:
Newsflash: archiving vendors have not designed their APIs with philanthropic intentions in mind.
Contrary to what some may want you to believe, archiving vendors don’t want to make it easy for you to stop using their platform. Archiving vendors make more profit selling their annual support agreements (and professional services) then they do on the initial archive sale. So the laws of business will tell you that they will not make it especially easily for a customer to move away from their platform. Many archiving vendors market the fact that they have supplied an API, to make full-scale migrations easier - but easier than what? For those of you who have actually worked for an archiving vendor, how often was your vendor “API” updated? What revision level is it on… one point something? The bottom line: archiving vendors do not spend a lot of time on their export APIs and usually don’t put the engineering varsity squad on creating and maintaining it. What does that tell you about relying on the API for your migration?
Let me put this as diplomatically as I can; reliance on archiving vendor APIs for data migration is borderline amateurish and shows a distinct lack of capability. As I mentioned in the paragraph above, vendor APIs are usually designed with a bare minimum of feature/functionality so as to not make it too easy to abandon their platform. A migration vendor who has to rely on the stated specs (because they’re not technically proficient enough to actually understand the archiving system), is not doing you any favors. For example, certain archiving vendor APIs limit an export rate to 1 TB per day - because either they didn’t want it to be faster or because they themselves couldn’t figure out how to speed up the export process. When in reality, bypassing the API allows an export rate of 5 TB or more per day.
A word of warning: your migration vendor (who is relying on the vendor API in the first place) may alert you that bypassing the API is not “supported”. Supported by whom we ask? The vendor that doesn’t want you to abandon their platform in the first place?
If you’re in the market to migrate your archive, here are some questions you should ask prospective vendors.
Questions to ask migration vendor relying on a vendor API:
Questions to ask all migration vendors:
At risk of being accused of deadly sin number one (pride), our team has grown up in the archiving world; some of us actually developed the archiving products you’re trying to move away from (as well as their APIs) and we have migrated more than 300 customers worldwide, all of whom are referenceable. Contact Archive360 for more information.
Your legal, compliance and security teams rely on having an immutable copy of all of your emails. Office 365 archiving does not support journaling. So what should we do?
This eBook provides actionable tips to empower IT to solve the problem.