Migrating Documents to Papyrus: Best Practices by Means of DOPiX and IBM’s ASF/DCF

Companies are sooner or later faced with the challenge to replace their outdated document composition systems. The recent announcement to stop maintenance for DOPiX has a big impact on especially the German market. Learn about the possibilities to migrate business documents from any source system into Papyrus and how that is seamlessly done for IBM’s ASF/DCF based documents.

Background

When existing document systems are to be retired due to several reasons like not being maintained anymore or home-grown applications must be finally replaced by standard solutions, it reaches C-level management attention and raises the awareness of the impact on daily production. Thus, it is a major concern how existent documents, building blocks and their content in combination with business logic can be preserved and migrated into a new system.

Migration Best Practices

Papyrus offers different approaches which have been established from many migration projects. An important aspect is to consider a consolidation of documents and building blocks as part of the migration process in order to experience the benefit of eliminated redundancies and inefficiencies that come from multiple document template maintenance efforts and usage for different output channels.

Papyrus has successfully migrated from different document management systems, customer communication applications or general purpose document and forms design products into the Papyrus platform, which can run on-premises on physical or virtual machines (Windows, Linux, AIX, HP-Unix, SUN, z/OS) or the Cloud: IBM ASF/DCF, icon DOPE/Dialog, OpenText / Exstream / StreamServe, Modus, Pitney Bowes Business Insight DOC1, Adobe design products, Assentis / Smart Communications, Kühne und Weyh M/TEXT as well as Quadient.

Experience tells that the main goal of migration projects is usually a consolidation of documents and contents for a single-source document management approach rather than the migration automation, although automation should be applied where feasible. A typical example are many forms which are similar (e.g. the name/address part of the forms) but not identical. Therefore, going one step further than just migrating them one-to-one is in focus and the goal is to make as many elements reusable as possible. This means a one-off investment resulting in significant future savings on maintenance. Thus, a fully automated one-to-one migration is neither desired nor possible, because of inconsistencies that have been established over years or even decades. Different document templates and text definitions exist in different systems. Such redundancies and ambiguities in content and also business logic should be eliminated by consolidation of document templates. This can be reached when the number of document text variants is reduced in the migration process and reusable building block templates are introduced.

Papyrus Business Designer

Papyrus Business Designer plays a key role as it empowers the business departments to take control and use the available migration tools to migrate all document assets into the central Papyrus resource library. All resources are fully version managed due to the embedded Change and Release Management.

Production processes for batch and on demand documents as well as interactive documents use the currently released resources in a fully transparent way. Time travels allow to reproduce documents from the past and simulate how a new document which will be released in the future will look like.

Example Migration: IBM’s ASF/DCF and DOPiX

IBM’s ASF/DCF documents can be easily migrated into the Papyrus Business Correspondence Solution using the dedicated Papyrus migration tool. The same applies for DOPiX, the German based document system, which evolved from ASF/DCF. A typical migration procedure starts with the import of existing AFP resources like fonts, images and forms. Document content is automatically converted during the import step into Papyrus Correspondence building blocks. The migration tool checks for already existing components for optimal reuse and creates new building blocks for not yet migrated content, including business logic.

Migration administrators use Papyrus Business Designer to verify the results and simulate with test data all relevant conditions. If needed, building blocks, positions, fonts, colors, etc. can be intuitively fine tuned before the release manager accepts the changes for user acceptance testing and finally for go live.

Conclusion

Papyrus provides different migration tools which have been developed and tested based on the requirements of previous migrations. Depending on the consolidation requirements manual adjustments to the migrated components are a natural part of a migration project. Changes and adaptations can be easily done by business administrators using Papyrus Business Designer. To find out more about the Papyrus capabilities read on our Website about Papyrus Correspondence Business Designer or order the Smart Document Design Best Practices document.