Seven REDCap-to-EDC migration mistakes

It is tempting to fix a compliance gap on a running study. Resist it. A mid-study move means two sets of records for the same participants, a cut-over date that every site has to hit and a possible conversation with your ethics committee about what participants must be told. Check with your IRB or ethics committee and sponsor rather than assuming. The safe pattern is to start the new platform on a new study, a future arm or a follow-on study, and let the running one finish where it is.

You cannot import a REDCap project directly into Capture. The data dictionary CSV lists every field, type and choice set, which makes it an excellent starting brief, not a finished build. Upload it (CSV, XLSX, PDF and DOCX are all readable) and the AI form builder drafts questions and tables for you to review. Nothing is saved without human review, and it only works on draft forms. Budget for the review, because that is where the time goes.

Old projects carry workarounds: free-text fields standing in for coded choices, repeated instruments that were really a table, calculated fields nobody trusts. A dictionary-to-form copy preserves all of it. Use the move to ask whether each field serves the protocol, and to apply cleaner structures such as repeating table sections for concomitant medications or labs, edit checks that raise queries automatically and calculated fields shown read-only during entry. Our CRF builder guide shows what is available, and CRF templates give you a standard starting point.

Simple show-and-hide conditions map directly to skip logic. Deeply nested expressions, or logic that leans on several calculated fields at once, may need simplifying to fit the visual builder. List them in advance, rank them by importance to the protocol and test each one in the sandbox with edge-case values. Every one you simplify should be a written decision, not an accident.

Direct import of REDCap data is not supported today, so the practical route is to export from REDCap as CSV and merge it with Capture exports at analysis. That works well only if you plan it: keep subject identifiers consistent, record the units and coding used in each system, keep both data dictionaries with the study files and write the merge rules into your data management plan. Our data management plan template has a place for this. If your analysts use CDISC, the SDTM export in Capture is SAS XPT with Define-XML.

Validation belongs to the system and to your use of it. Whatever you did for REDCap tells you nothing about a different platform. Plan user acceptance testing against your own requirements and keep the evidence. The EDC validation checklist and the UAT sandbox guide give a structure. Capture's controls are 21 CFR Part 11-aligned, including a field-level audit trail with user, timestamp, old value, new value and reason for change, but part 11 compliance is a shared responsibility between the software and your validated use of it.

Projects on any system pick up informal habits, such as a shared login for a coordinator. In Capture, access is role-based (researcher, site coordinator, admin), site coordinators see participant names while researchers see coded IDs, and sites join through a QR code with site-level participant numbering. Map your current users onto those roles before go-live, train them in the sandbox and decide who owns amendments. Skipping this is why a technically clean migration still feels broken on the first day.