How do I migrate custom fields between project-management platforms?

Treat the migration as a mapping exercise, not just a field-name copy. For every source field, record its name, type, allowed values, whether it must be filled in, and how existing records use it. Then identify a destination field with compatible meaning and behavior. A matching name alone does not prove the fields are equivalent.

For example, a source field called “Urgency” might be a single-choice field with values “Low,” “Normal,” and “High.” The destination mapping should preserve that meaning and those choices—or document an intentional change. Keep a list of fields that have no direct destination equivalent instead of silently dropping them.

Use one row per source field, with columns for source name and type; sample values; allowed values; required or optional behavior; destination field and type; destination allowed values; and the planned action for any mismatch. Add a notes column for transformations or questions to resolve.

Here is a copyable template. The entries are placeholders, not a claim about any particular platform:

Source field | Source type | Source choices or format | Required? | Destination field | Destination type | Destination choices or format | Mismatch and decision | Test record Urgency | Single choice | Low; Normal; High | Optional | [destination field] | [type] | [destination choices] | [map or revise choices] | [sample item] [date field] | [source type] | [date format or examples] | [yes/no] | [destination field] | [type] | [expected format] | [conversion or exception] | [sample item]

Check whether the destination can represent the source’s meaning, not just its broad type. If choices differ, write down how each source choice will map; do not assume similarly named choices are identical.

Mark each mismatch explicitly and choose a deliberate treatment: map to a suitable existing field, create a destination field if available, transform values, split or combine fields, or exclude the field after deciding its information is not needed. Record who will confirm the decision and how you will check the result. If there is no safe equivalent, preserve the source information in an agreed separate form rather than forcing it into a misleading field.

Required-field behavior needs its own check. Compare whether each field is required at the source and destination, and identify records where the value is blank or unavailable. Do not invent replacement values just to satisfy a destination requirement; decide how those records should be handled before importing.

The cited Jira guidance illustrates why the exact route matters: for one Jira business-space-to-software-space import, the review screen allows field mapping and inclusion choices, while Summary is required and Category is unsupported [S1]. In a separate Jira Server-to-Cloud Migration Assistant route, Atlassian warns that a required field with a null value can cause migration failure [S2]. These are route-specific examples, not rules for other platforms, and they do not establish how arbitrary allowed-value sets map.

Use a small test import if your migration route supports one, and choose records that exercise the mapping: one for each important choice, a blank value, a less common value, and any known exception. Compare the source and destination field values against your mapping document. Also check that required fields behave as expected and that excluded or unsupported fields are accounted for.

For instance, in a hypothetical test, “High” urgency should land in the destination choice you documented, while a blank optional value should remain blank if that is the intended mapping. If a result differs, update the mapping and repeat the relevant check before scaling up. Keep a record of the decisions and unresolved limitations for anyone reviewing the migrated project.

The Jira examples above do not establish the behavior of other products, or provide a complete cross-platform mapping method. Verify requirements and supported field configurations in the documentation for your specific source, destination, and migration route.