For a long time, on-premise hosting was favored by organizations that could afford the cost of implementation and maintenance, with the objective of keeping direct control over these large volumes of data. The multiplication of SaaS offers, and then cloud offers in recent years, has made it possible to provide organizations with lighter offers that are less costly in terms of resources and skills, since the effort is shifted to hosting providers, and integrators.

Today, the cloud is the preferred target destination for storing documents because of its low cost in relation to the volume of storage and the security strategies (backup, replication) that it allows to consider in a simpler way than in physical environments.
Of course, it is important to select a cloud offering (public or private) that meets the requirements of security, sovereignty, and specific data protection (HDS, specific ISO standards 013, 020) in relation to the nature of the documents stored.

But this being said, we must not confuse cloud storage and document solution on cloud, especially SaaS (software as a service) solutions which require special attention.

Compare approaches: On Premise, PaaS, SaaS

• In an "On premise" approach, installed on the customer's servers, the customer has complete control over his document solution (he can customize it as needed) and the operation that goes with it on his data center(s). Everything is under his responsibility and that of his subcontractors. This model has the advantage of a very high degree of independence, good cost predictability, at the cost of a substantial initial investment and the need to exercise continuous vigilance over time in the application of backup and disaster recovery procedures. The TCO total cost of ownership, even if it decreases over time, remains generally higher than via cloud hosting with equivalent performance/services (availability rate, etc.).

• In a "PaaS" (platform as a service) approach, the on-premise solution is transposed to a cloud environment. The document solution used remains the one chosen by the customer, he can customize it if he wishes and the technical components used, database, search service, directory service, transformation service - except storage - remain the same as those of a localized architecture (1).
  We can therefore consider that the solution remains globally portable and that the customer can easily consider transferring it to another cloud provider or repatriating it to its own environments.
  The cost model remains clear because it is based on an investment (the construction of the platform and software licenses) and the purchase of fairly simple services from the cloud provider (storage consumption, CPU consumption, consumption of flow and security services).
  This type of architecture is often optimal for an ECM solution, because it allows the same document management platform, depending on the nature of the documents, to address different storage services (hot or cold), either commonplace or ultra-secure (HDS for example).

• In a "SaaS" approach, software as a service, the model is completely different since the customer rents the entire document service. This approach can be attractive because of its simplicity of implementation and progressive pricing (with a very low investment), but you need to be aware of its limitations. To begin with, it is necessary to verify (as with PaaS) the location of the document service and the associated storage, as well as the security standards or protocols covered. You must check the functional coverage of the solution, because it will not be possible to make changes or enhancements on your own initiative.

Project your hosting on a long term model

The cost model and its progressiveness (per user, per document, per storage volume, per transaction, per additional services used, etc.) must be carefully studied. It is often a "mix" and the customer must therefore make different assumptions to anticipate the future costs of his solution. Finally - and this is essential in the document domain where retention periods are often long - it is necessary to ensure the reversibility of the system in the event of a service failure or the desire to interrupt it. And integrate into this analysis the fact that the value of a document system does not stop at the document: it includes the metadata, the classification plans associated with the documents, the user rights associated with the classification plan or the documents, the space models, the relationships, etc. It is therefore the complete model that must be able to export at regular intervals, otherwise a significant part of the document investment will disappear when the service is suspended.