Unavoidable in the long term

For SAP, an archive is exclusively a data sink in the sense of an external data store. Access to "outsourced" data and documents takes place via a so-called primary key; all metadata required for a search are managed within SAP as the leading system.

The advantage of this working principle: An archiving system needs neither its own logic for metadata management nor its own authorization system. Classic DMS or ECM systems bring system-dependent functions with them that are already available in the SAP system and are therefore redundant or completely superfluous.

Therefore, a pure archive that focuses only on supporting the standardized ArchiveLink interface is always preferable in the SAP environment.

For this reason, the only question that really remains is how the existing DMS/ECM system can be migrated to a high-performance and robust archiving system without much effort. Above all, the central requirement for document and data availability during the migration can only be achieved with good planning, especially since migration processes usually involve considerable runtimes.

The actual runtime depends not only on the source archive, but also on factors such as the performance of the target system and backup times. In addition, any "frozen zones" in which migration is not possible can sometimes have a significant impact on the runtime.

Only if the archive migration can also be carried out smoothly and securely during a normal working week is there sufficient document availability during the migration.

In SAP or outside?

First, it must be determined whether the migration is to be performed inside or outside the SAP system.

Since SAP can only address different archive systems via different content repositories, SAP-side migrations always involve copying from one content repository to another and then cleaning up the link tables.

Overall, the decisive disadvantage of this approach is that the necessary interventions in the productive SAP landscape involve significant risks and require very complex change management in this regard - especially for large companies and corporations - this is often an insurmountable barrier.

Regardless of the disadvantages, an SAP-side migration procedure is always sensible and necessary if, in addition to the migration, cleanups are also necessary in the archive inventory. Otherwise, it is advisable to run the migration outside the SAP systems involved.

This approach requires the use of suitable software, i.e. a migration proxy server, such as KGS Migration4ArchiveLink. This does not require any changes to be made in SAP and the migration is completely transparent for all users.

All administrative activities can be performed without SAP access; even the physical migration - i.e. copying the archive objects - takes place outside SAP and can therefore be continued even when the SAP system is switched off.

Furthermore, no changes have to be made to the SAP link tables, as this procedure allows copying a content repository to a repository with the same name. In the case of archive accesses from SAP, the migration server behaves similar to a proxy server in the network and forwards the requests to the correct archive system. A migration database is used for logging purposes.

Archive migrations can be postponed, but not permanently. Projects are often triggered by the discontinuation of software versions of the existing archive/ECM solution or by a change of storage system.

From practical experience, it can be stated: If a company can achieve technological improvements, such as higher integration depth, better performance and higher stability, and if, on the other hand, economic reasons, such as lower costs, are also required - then it is time to say goodbye to the legacy archive and migrate it to a new platform.