FAQ - ECM Data Conversion & Migrations
FAQ - What's the Difference between an Export (tool) and a Professional Conversion?
Original system intent / utilization?
Export:
An export asks the legacy system to do something it can often do - but was never designed for. The stress of unloading 7-10 years of data is also hard to predict and can interfere with daily use and even cause support issues. Exporting from a system that is EOL or not currently supported can be dangerous.
Conversion:
The conversion avoids using the legacy system to do the work and instead processes the data in purpose built workflows designed for this task.
What about System stability when doing an Export vs a Conversion
Export:
The legacy system would need to be fully functional and operational if it were being used for an export. This can also complicate daily use (external of the export) as system resources can become strained.
Conversion:
The conversion relies on a database backup and repository in its native file system format, thus not requiring or interfering with the legacy systems operation - providing it is operational at all.
What happens if the legacy system fails - during an Export of Conversion?
Export:
A system failure will stop the export (hopefully with a well defined recovery point) and stop serving its primary function for daily users.
Conversion:
The conversion is unaffected by the Legacy system failure and actually can provide a stop gap as documents can still be made available. Conversions can and often take place once systems have fallen out of maintenance or are not fully operational.
How does an Export differ from a Conversion regarding file types?
Export:
The export often times relies on the file type or mime type in the application database. There is no confirmation or verification that this information is correct - it is simply trusted. Some vendors actually place language in the "conversion" contracts noting that mistakes in the original application and consequently in deliverables are not their responsibility.
Conversion:
A well done conversion will stand out here for two distinct factors. First there will be a binary interrogation of every file to determine what it is and that it is not zero length. This binary review process ensures that good files get properly named for import and are usable in the new ECM system.
Secondly, the conversion process will do cryptographic hashes as files/documents move throughout the workflow ensuring file level integrity.
How does annotation handling differ between an Export and a Convrersion?
Export:
An export will either ignore or skip annotations altogether or at best, will flatten them onto the exported image. This causes issues such as:
- Annotation security is lost - its just there.
- Two documents now replace one - one unannotated and one annotated. (Flattened annotations will "redact" whatever is behind them - so a clean document copy is required otherwise document content will be lost).
- Users will now have to review two documents instead of one.
- Rules and policies need to be put in place for which document should get future annotations.
- If documents can be public facing, portal rules will have to not grab internally annotated legacy files.
- The next migration may now create/require three copies of a document; clean, old annotated, new annotated.
- For hosted systems there will be increased storage costs.
Conversion:
A quality conversion vendor will process legacy annotations into an import format for the new target application. Not all annotation types or formats move 1:1 but intent, content and context can be preserved providing and definsible transition.
The imported annotations are live annotations and act just like new annotations being applied by a user. Documents have one copy with an annotation layer - regardless if they're legacy or newly applied annotations.
FAQ - What are the implications of just leaving my system in read-only mode for the next 7-10 years?
Will I have to pay a subscription or maintenance costs if I just leave my system in place instead of doing a conversion?
While you might not have to pay maintenance costs - you will certainly have subscription costs if that is how you are currently licensed. It's worth noting that many vendors will not allow you "back on" maintenance if you leave - so if your system goes down - you likely have to buy new software.
Some organizations will also not allow a source of record or production level system to run without maintenance and further run on outdated or unsupported hardware or OS.
Will my costs (maintenance and subscription) increase over time?
Many vendors have what is called an annual uptick. These increases vary in size but can reach 7-10%. Several vendors also don't let you downsize (reduce user counts) so despite what might be a drastic reduction in use - costs remain the same.
Also worth keeping in mind is forced upgrades. Vendors change extended maintenance for system so many versions back so when planning out this strategy - you should include the cost of upgrades - say every two years or the costs of extended maintenance.
With a 10% uptick - your costs will just about double every 7 years.
Outside of costs - what risks can be associated with this strategy?
There are several risks associated with "put it in the corner" strategy - beyond escalating costs:
- Current hardware may become obsolete and the legacy software may not support newer versions.
- The OS and database may too become obsolete and without upgrades - may not support the legacy ECM environment.
- If you're not upgrading all your items (software, OS, database and hardware) you may get to a point where something simply stops working.
- It can be difficult to keep staff around (admin) that can work with the legacy ECM system once it has been mothballed.
- OSs and databases in particular get constant security updates - failing to do this could place mission critical data in an unsafe exposed state.
FAQ - What if I integrate my new ECM system with the legacy one?
What would be involved with this approach?
Integrating two systems has definitely gotten easier over the years but there are many considerations when viewing this approach?
- What are my long term goals regarding ECM and does supporting multiple platforms over an extended period of time (think at least 7 years) fit that strategy?
- If my legacy system is still going to serve as a repository of record, what will my maintenance costs, uptick costs and potential upgrade and hardware change costs be over that period of time?
- Can I ensure that I have trained staff to support upgrades, new integration requirements as technology changes over 5-7-10 years?
- If my legacy product is EOL or on an EOL schedule - how will that impact tis integration over time?
Could my legacy system costs actually increase using this approach?
Legacy ECM systems costs could actually increase depending on your particular system and it's licensing language. Legacy software was often licensed by concurrent or named user, seat based operator or authorized user. API's, portals, service accounts, consolidated front ends were prohibited from reducing required licenses. These items were addressed or labeled as indirect access, multiplexing or third-party portals.
This new solution could require more not fewer licenses. If not blocked by technology (being locked out) subsequent vendor audits could yield disastrous and very expensive surprises.
When would it be better to integrate my new ECM with a legacy ECM vs doing a conversion?
The case to be made for integrating the two ECM platforms - outside of "it's cool AI" would be the following:
- The new ECM is not directly replacing the old ECM.
- The ECM applications - new or old - are not integrated into a Line of Business application (Epic, Workday, SAP, etc.)
- The document retention requirements for documents in the legacy system is less than the expected life of the new system. For example - a Life Insurance Co. may have to keep documents 25 years after an insured has past. If integration was the approach - these documents could span 3 or 4 ECM systems.
- Documents in the legacy system are not subject to or could be subject to legal holds.
- The documents in the legacy system are not subject to or managed under an inforce retention schedule.
When is conversion the better option?
The conversion - as much as it is not the sexy AI driven approach - is a better option in many cases.
- The legacy system is being fundamentally replaced with new system. Why have two systems doing the job of one?
- Costs and risks matter. Conversion can be a large one time expense - but the cost of integration, maintenance, user audit risk, potential EOL status, outdated or insecure OS or database layers are hard to quantify over 7-10+ years.
- Format risk. Many legacy systems utilize proprietary or at least "old" formats that might not still be usable a decade from now. A good conversion identifies these items (binary level) and repurposes them for long term usability.
- It may be easier to apply retention rules during a conversion than it would be to go back into your legacy system and do it. Properly applied retention rules lowers overall storage costs but more importantly reduces exposure risk from keeping documents well beyond their required life.
- A conversion also affords the opportunity to fix things. Consolidate document types, indexes, index formatting, file formatting, and retention as mentioned earlier.
- When you don't have or will not have the infrastructure or staff to maintain a legacy environment for the life of it's documents.