When migrating between systems, it is crucial to define the scope of implementation, as well as to outline each stage of the project and the resources that will be needed. A failed implementation will paralyze the operational capabilities of an organization, but the right methodology will help ensure a successful implementation.

In the issues related to the areas of ERP and PLM integration, we’ll highlight relevant areas of consideration. Furthermore, you’ll learn what steps can be taken to safeguard purging and data retention. This is a legal and mandatory business consideration.

We’ll assume for the purposes of this blog post that a new system exists, and that we are migrating data from an existing legacy system to a new ERP/PLM system. This can be viewed as an in-house system upgrade, or as migration of data from a purchased company.

Purging and Data Retention

When production databases become too large, they impact productivity by slowing access to information, and by extending the time required for system backups or for system restores.

Depending upon the industry (for example, medical, government, etc.), the need for data retention varies based on regulatory compliance. Some industries have long duration product guarantees, which results in the necessity to retain data.

Archiving has evolved into a discipline known as information lifecycle management (ILM). ILM helps organizations maximize the business management of storage from creation to disposal. Management is understandably reluctant to perform data purges due to the unknown operational risks, and it is therefore often done in stages.

Unstructured data populates file servers and typically includes e-mails, drawings, and user- and application-generated files in hundreds of unique formats. Purging can be by date, by type (internal or external), and by inbound or outbound status. Nevertheless, while many IT shops are only archiving e-mail to a less expensive tier of storage, they are still unwilling to permanently purge e-mail for legal or operational reasons.

The usual approach consists of transfer of data from active tables to online historical backups on a monthly basis. Since historical data is essentially invariant for long periods, it does not require being re-backed up if it had no changes. The backup facility may also make a second copy to non-rewritable storage. In the process of creating archives, an accompanying step is often taken to create summary data into a data-warehousing product for business intelligence studies. Summary data allows a look at a product’s sales figures for a given time period, by examining a single entry in a table rather then summing up individual sales order lines.

0 comments:

Newer Post Older Post Home