Translations:Maintenance: Preservation, Development and Migrations/47/en: Difference between revisions

From Wiki
(Importing a new version from external source)
 
(No difference)

Latest revision as of 06:53, 28 February 2024

Information about message (contribute)
This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.
Message definition (Maintenance: Preservation, Development and Migrations)
* Whether we are migrating data, software, or storage media, we should always include a set of preservation actions—including checkups of fixity, validity, and quality assurance—as a mandatory step before and after the actual transfer of files.
* For file format migration, it is important always to retain the original file along with the new migrated file, as the migrated file might have lost some of the properties of the original file, which is not always detectable by the software. In such a case, we will have to decide what data we consider acceptable to lose (if any).
* To reduce the risk of changes to files going unnoticed by our software during file format migration, it would be a good idea to plan for a quality control test as part of the migration process. This would include manually opening and checking a reasonably sized sample of migrated files based on a set of acceptance criteria we develop. For example, it's formatting, look and feel, and functionality.
* For software and storage media migration, it is also a good practice to retain the original files for an appropriate period of time following the migration—anything from a few days up to a year or longer, depending on the type of migration. This is because, frequently, it is only post hoc that we discover process shortcomings or data changes that occurred during the migration. We can repeat the process and avoid data change if we retain the originals.
* We should always include backup copies in any migration plans and workflows and make sure that after the migration is completed, new backup copies are created from the migrated master files.
  • Whether we are migrating data, software, or storage media, we should always include a set of preservation actions—including checkups of fixity, validity, and quality assurance—as a mandatory step before and after the actual transfer of files.
  • For file format migration, it is important always to retain the original file along with the new migrated file, as the migrated file might have lost some of the properties of the original file, which is not always detectable by the software. In such a case, we will have to decide what data we consider acceptable to lose (if any).
  • To reduce the risk of changes to files going unnoticed by our software during file format migration, it would be a good idea to plan for a quality control test as part of the migration process. This would include manually opening and checking a reasonably sized sample of migrated files based on a set of acceptance criteria we develop. For example, it's formatting, look and feel, and functionality.
  • For software and storage media migration, it is also a good practice to retain the original files for an appropriate period of time following the migration—anything from a few days up to a year or longer, depending on the type of migration. This is because, frequently, it is only post hoc that we discover process shortcomings or data changes that occurred during the migration. We can repeat the process and avoid data change if we retain the originals.
  • We should always include backup copies in any migration plans and workflows and make sure that after the migration is completed, new backup copies are created from the migrated master files.