This topic describes the different ways you can migrate your data.
You can use standard copy commands or utilities that are provided by the client operating system to migrate your data (for example, cp, cpio, or tar commands on UNIX® and the xcopy command or Explorer on Windows®). You can also use backup applications to restore data from the latest backup into the SAN File System as the destination. These methods work best when migrating large numbers of small files.
Migrating data using the migratedata utility is a disruptive process. This means that, to guarantee data integrity, you must stop all applications and users from modifying the data being migrated (including database and application servers) until the migration is complete. Only the data being migrated must remain unchanged. To minimize the impact of a migration, a service technician can migrate your data in chunks rather than all at one time. If your environment cannot handle a disruption in service, the migratedata utility might not be the best tool for your migrating your data.
If you are migrating an IBM® DB2® environment, the procedures vary depending on whether your environment is file-system based or contains raw configuration devices. For a file-system-based environment, a service technician can use the migratedata utility to migrate your files, and then reconfigure DB2 to reflect the data movement. For raw configuration devices, the service technician must use the DB2 unload command to move data out of the raw devices to a temporary holding location, and then perform a load operation to place the data in its location in the global namespace. After the data is loaded into the global namespace, it is file based.
If you are migrating a Microsoft® Exchange database from NTFS to SAN File System, use Exchange-supplied tools rather than the migratedata utility to ensure that the user configuration data and parameters are also migrated.
Parent topic: Planning the data migration strategy