Archive migration: not avoidable in the long-run

The practice when changing archive systems in the SAP environment.

 Archive migration: not avoidable in the long-run,

by Bernhard Morell, senior consultant for SAP archiving at KGS Software GmbH & Co. KG.

The migration of archive systems has kept consultants, users and IT departments busy ever since archives have been around, also in the SAP environment. They can have many reasons: mergers of companies, realignment and streamlining of the IT environment or lowering operating costs. A company may also want to focus on the necessary functions of an archive – especially for SAP, there are archive systems that only provide the functions necessary for SAP – and therefore abolish its old solution.

For SAP, an archive is solely a data sink in the sense of an external data memory. Access to outsourced data and documents takes place via a so-called primary key. All the metadata necessary for a search are managed within SAP as the leading system. So there is no need for SAP-independent document access. An advantage of this philosophy: an archive system does not require its own logic for metadata management nor a separate authorization system.

Especially in light of today’s existing modern storage and HSM technologies, classic archive/DMS or ECM systems with their broad functionality are therefore basically no longer required in the SAP environment. This is tantamount to a paradigm shift in archiving: the archive focuses only on the support of the standardized interface ArchiveLink, the efficient management of the metadata necessary for storage and access, and the optimized approach to memory systems used for storage.

Requirements from an administrative and user perspective:

In general for migrations:

  1. All documents and data should remain accessible during the archive migration
  2. The migration should take place as automated as possible
  3. Complete proof of the completeness of the migration must be kept
  4. An archive system migration must not require application changes, in particular in the production environment
  5. The archive system replacement must be transparent for the user
  6. Migration processes need to be robust and have the ability to restart

We can distinguish between two broad categories here: on the one hand administrative as well as system requirements, and user requirements on the other hand. The administrative requirements are usually easily met, because a fully logged and automated migration can be easily implemented with different approaches today.

The user needs require a closer analysis. Particularly the central demand for document and data availability during migration can only be achieved through good planning, especially since migration processes are usually associated with a significantly long running time (see table with running time calculation). The actual running time depends not only on the source archive, but also on factors such as the target system and backup times. Additionally, possible “frozen zones” in which migration cannot take place, can significantly affect the running time.

Figure 1: Rough running time calculation of archive migrations (all values rounded)

Migrated documents per second

Document volume

Migration running time in number of days (at 24 hour running time)

Migration running time in number of days (at 12 hour running time)

1

5.000.000

58

116

5

5.000.000

12

24

10

5.000.000

6

12

100

5.000.000

1

2

1

10.000.000

1158

2315

5

10.000.000

232

463

10

10.000.000

116

232

 

Only when the archive migration is to be performed safely in the course of a working week, is sufficient document availability given during the migration. Exceptions to this are documents linked to work items in the SAP workflow that require timely processing.

Migrate within or outside of SAP?

Firstly it is necessary to determine whether the migration should be conducted within or outside of the SAP system. Migrations within SAP need to particularly take into account the characteristics of the archive link. SAP manages all archived objects in so-called linking tables. Access to archived objects thus always occurs over the content repository in combination with the document ID.

It is in this regulation that the challenge of a migration within SAP arises. Since SAP can address different archiving systems exclusively through different content repositories, migrations within SAP are always associated with the recopying from one content repository to another and consequently a clean up of the linking table. For this, various SAP reports and function modules can be used and combined to a more or less semi-automated process. However, existing reports in the SAP standard only include insufficient protocol capabilities, so errors can only be dealt with inadequately.

Migrations within SAP also consume SAP resources and can have negative effects on the performance of the system. The requirements of unlimited document access during migration on the other hand, will be met. Overall, the main disadvantage of this approach is that the necessary intervention into the productive SAP landscape carries with it substantial risks and thus requires a very complex change management – especially for large companies and corporations this is often an insurmountable inhibition threshold.

Notwithstanding the disadvantages, a migration process within SAP is always useful and required when, in addition to the migration, a cleanup of the archive content is also required. This may be the case for the division of existing content repositories to multiple target archives, merging of different content repositories into one common repository, partial transfers of archives into new archives or changes to print lists or data archives, such as when merging different SAP systems.

If none of the above applies, it is advisable to run the migration outside of the participating SAP systems (see figure “SAP archive migration outside of SAP”). This procedure requires the use of suitable software – a migration proxy server. For this, no changes need to be made in SAP and the migration is completely transparent to all users. Various administrative tasks can be performed without SAP access; even the physical migration – i.e. copying the archive objects – takes place outside of SAP and can therefore be continued even when the SAP system is switched off.

No further changes have to be made to the SAP linking table, since this process allows the copying of a content repository into a repository with the same name. The migration server behaves similarly to a proxy server in the network and forwards requests to the correct archiving system. A migration database is used in this approach for logging.

Process in the project

Archive migration projects can be divided into the phases of conception, migration testing and migration runs. The focus of the project lies on the conception and screening of source archives and all existing applications. Often, many of these are no longer used. The way of dealing with these and whether they may still be subject to a storage obligation must then be determined. The active scenarios must further be checked for necessary cleanup work (data format conversions, merging of content repositories, altered retention periods, etc.).

Only then can the configuration of the migration commence. The migration test then represents the second phase of the project, which is used to test the concept and reliably estimate the running time. Knowing the running time is important to be able to approximately estimate the time of termination of service contracts for the old system or to determine expenses for internal and external resources.

The final phase involves the actual migration of the productive archive. This is characterized by regular checks on the progress and for possible problem, such as no longer readable documents. At the end of the migration, the full migration log is added to the existing process documentation. Thus, all legal conditions are met.

How useful are archive migration projects?

Although archive migrations can be delayed, they cannot be evaded in the long-run. Projects are often triggered by the discontinuation of software versions of the existing Archive or ECM solution. From practical experience, it can be stated that if a company can accomplish technological improvements such a higher level of integration, better performance and greater stability, and additionally also has economic demands such as lower costs, then it is time to say goodbye to the old archive and to migrate it onto a new platform.

×
de-flag
Wählen Sie Ihre bevorzugte Sprache.
us-flag
Choose your preffered language.