Who this is for. The developer releasing work that was built on a development platform or another account, with a super administrator's access to both. Afterwards you can move each kind of record in the right order and show that the target works.
This page applies when the work was built on a different database from the one it is released on. Between the environments of one site there is nothing to move, because they share their records (within one site); and between sites of one account, input types, custom fields and settings are already shared. Deploy the code first in every case, so that each record arrives on a site that already has the files it points at.
The export and import
The admin's Export data screen (/cdna-admin/sites/export) writes a file of chosen records of five kinds: layouts, input types, custom fields, settings and jobs, with the layout and job categories they sit in. Import data (/cdna-admin/sites/import) on the target reads it, in the order input types, layout categories, layouts, custom fields, settings, job categories, jobs. Both screens are for super administrators only. Forms, menus, site data, redirects and content are not part of the export.
The import recognises a record from an earlier export or import of the same records, or by its unique properties, and the Update existing records option decides what happens to it:
- Off, the default: a record that already exists is skipped whole. A layout already on the target keeps its old areas even if the file has new ones. Use this the first time.
- On: the whole record is brought in line with the file, children included. That also removes what the file does not have: a layout with four areas on the target and two in the file ends with two. Use it only to update records that came from an earlier export.
The file carries a checksum, and an edited file is refused unless Skip checksum checking is ticked. One invalid record stops the whole import unless Skip invalid records is ticked; leave it off, and fix what the error names.
The procedure for each kind of record
| Record | How to move it | Re-enter or check afterwards |
|---|---|---|
| Input types | Export, with or before the layouts that use them | Select options, which are data and may differ on the target |
| Layouts and their areas | Export; or create the layout in the admin from the same template | Area groups and attributes; the components each collection accepts; which records use the layout |
| Custom fields | Export | The records the fields apply to |
| Jobs | Export and import, following Move jobs from staging to production safely | The site each job is limited to and every schedule, both empty after an import; record ids in conditions and actions |
| Forms | Recreate in the admin, or through the REST API | Every template and job that refers to a form, and each form's payment element |
| Settings | Export only the ones that changed, or set them in the admin | That they are account-wide on the target, and anything the target's .settings.json overrides |
| Site data | Set by hand on the target | Keys and URLs for the target's own partners, never copied from the build copy |
| Menus | Recreate with the same names, since templates find menus by name | Links that point at the build copy's URLs |
| Search views, fields and facets | Recreate | The facets mapping template, entered per environment; then reindex |
| Redirects | Import from a file through the REST API (importing in bulk) | That each is published |
Verification
A move is finished when the target is shown to work, not when the import completes:
- Compare the lists. List the moved records on both sides by name, in the admin or through the REST API, and account for every difference.
- Render each page type that uses a moved layout, signed out, and check that every area shows, since a component layout whose template is missing renders blank, with no error to flag it.
- Run each job once with a real but harmless record, and read its job run.
- Submit each form once, and check where the submission and its notifications went.
- Read the template errors for the last hour (Reading the error log and tracing a request).
Keep the list of what moved, with the date and the export file, next to the code in the repository. The next move is then checked against it instead of reconstructed from memory.