Limitations and obstacles to a cloud migration
The following section provides an overview of the limitations and obstacles you may face when migrating d.velop documents to the cloud.
Limitations of a cloud migration
As a rule, not all configurations, customizations, products and other settings of an on-premises system can be completely migrated to the cloud. You should therefore be open with customers that a cloud migration will result in changes. In the public cloud, for example, the options for repository configuration and the mapping of hooks vary. You can analyze the repository configuration with the d.velop cloud migration toolkit. This will provide you with a list of the obstacles for your specific case. You can purchase the d.velop cloud migration toolkit at the following link: https://store.d-velop.com/en/d.velop-cloud-migration-toolkit/90000003-en
Currently, systems with more than 100 million documents cannot be operated in a public cloud. Migrated documents are an exception to this rule.
It is generally not possible to access d.3 servers directly via D3FC in a public cloud. This includes, for example, validations against d.3 in d.capture batch (d.3 validate module), d.3 calls in d.cold and addressing the d.3 API in d.ecs forms. Direct access to the d.3 database is also not possible. The only way to access documents and dossiers in cloud systems is via the DMS API.
d.3 web webservice is not available in the cloud and therefore can no longer be used. Alternatively, you can use the DMS API, which requires you to switch over to the REST API.
JPL and Groovy hooks cannot be used in a public cloud. It is therefore necessary to switch over to webhooks or d.velop custom logics and d.velop business objects. You can find more information about working with hooks in the section How do I handle hooks in a cloud migration?
As a rule, workflows from an on-premises system cannot be fully executed in the cloud. Workflows like these must be created in d.velop process studio based on a new workflow engine.
Existing host import processes can still be mapped in the cloud using d.velop cloud uploader. However, more unusual functions such as database queries and logics (e.g. if statements) in JPL files cannot be used. You can find more information on mapping existing host import processes in the section How do I perform the host import in the cloud using d.velop cloud importer?
Currently, d.velop documents systems with document structure encryption can be exported only with the dmsdocs export API. The dmsdocs export API is available from d.3 server from version 8.39.0. The standalone export API cannot export the encrypted documents. More information is available at the following link: https://help.d-velop.de/docs/en/pub/documents-repo-export-developer/1.0.0/using-the-api-functions/activating-the-api-for-on-premises. This means older encrypted systems cannot be migrated without an update to version 8.39.0 or higher beforehand. This is particularly the case with Human Resources archives.
In rare cases, these limitations may mean that customers cannot use a public cloud system. Given these circumstances, a private cloud system is an alternative that is free of such limitations. In these cases, contact d.velop Support.
Obstacles to a cloud migration
At present, no more than 100 entries can be configured in multiple fields in the cloud. In on-premises systems, you can increase the maximum number of possible multiple field entries up to 2000. Documents with more than 100 entries therefore cannot be migrated. In this case, contact d.velop Support.
Annotations can be added to documents that have permission in on-premises systems. These annotations are not available in the cloud.
System fields (SysValues) that are no longer available in cloud systems can be used in on-premises systems. The system fields are used in e-mail archiving, for example.