Select Architect from the list of modules on the Rave home page.
Select a project from the list of Active projects on the Architect main page.
Click 
Amendment Manager link from the list of Project items.
The Amendment Manager module within Architect enables users to migrate existing subject data from one CRF version to another.
The Amendment Manager link in Architect displays when the following conditions are met:
The user has Amendment Manager Plan, Amendment Manager Execute Aux, and Amendment Manager Execute Prod Role Actions
There are at least two published CRF versions.
Permissions are set from Configuration > Security Roles > Actions.
CRF Migration can be applied to a study environment (for example, upgrade all CRF version 1 subjects to CRF version 2), entire site groups, entire sites, or selected subjects.
Select Architect from the list of modules on the Rave home page.
Select a project from the list of Active projects on the Architect main page.
Click Amendment Manager link from the list of Project items.
The Amendment Manager main page displays. You can generate a migration plan from this page, schedule a migration job in the Scheduler or view migration results of completed or in process migration jobs
On creation of a migration plan, the links on the left pane appear dynamically based on your user permissions, the existence of subjects in the source CRF, and whether there are errors in the migration process.
For each Source or Target version combination, the system goes through two processes:
The system generates a migration plan based on an automatic mapping of objects between Source and Targets CRF versions based on their OIDs. Any differences in unresolved mappings display so that they can be resolved. During the planning process, the system allows you to override system mappings as well as manually determine the actions for Source and Target objects.
There are numerous settings that can be configured for system behavior during migration, such as, break signature conditions for changes occurring during the migration.
Prior to executing the migration, you can perform a dry-run migration for impact analysis of the migration on subject data.
If there are no errors in the Migration plan, the system allows subjects to be added to the plan and scheduled for execution. The system then runs the plan to update all data points for the subjects.
During migration, you cannot access the subject in the EDC module or the reports. An audit trail is kept for all data points touched during migration.
Copyright © 2014 Medidata Solutions, Inc. All rights reserved.