How to Migrate Plasmid Files After Changing Design Software

Plasmid file migration is the controlled transfer of sequence, annotations, and construct identity from one design program into another without silent feature loss. Changing software after adopting a new tool often keeps the nucleotide string while dropping qualifiers, strand, or custom feature names.

To migrate plasmid files, export gb, gbk, dna, and fasta copies, remap features after import, then confirm identity with a diagnostic digest and sequence comparison. Keep the old application read-only until those checks pass.

Why Plasmid Files Break When Design Software Changes

The step looks simple: export a map, import it, keep working. The consequence is a file that opens, shows a circle, and is still the wrong scientific object. Feature names collapse to generic labels, primer binding sites vanish, and a custom CDS qualifier never arrives. Cloning then proceeds from a map that no longer matches the freezer stock.

The evaluation axis is scientific continuity, not whether the importer reports success. Continuity means the nucleotide string is identical, the feature table still explains the construct, and a second person can find the same plasmid by ID and version. If any of those fail, the lab has a pretty picture, not a migrated design.

Treat migration as a cutover project. Inventory the working set, choose export formats, import into a sandbox, map features, validate, then freeze the old tool as read-only. Do not delete the source files when the first plasmid "looks fine." Looking fine is not a sequence identity test.

Formats That Survive Import: gb, gbk, dna, and fasta

No single plasmid format carries every layer a design program uses. Plan a small export set per construct so the new tool has a sequence source, an annotation source, and a fallback if one parser fails.

Export GenBank as the annotation carrier and FASTA as the sequence witness. Keep the original .dna or other native file beside those exports. If the new software claims to open .dna directly, still keep a .gb or .gbk copy, because a later version of either tool may parse the binary schema differently.

Name the four artifacts with the same construct ID and version so they can be compared. A migration that stores "export1.gb" next to "final_v3.dna" is already a identity problem, even if both files are correct.

Annotation Loss and Feature Mapping After Conversion

Annotation loss is usually a mapping problem, not a missing nucleotide. Importers translate feature keys they recognize and skip or flatten the rest. A "primer_bind" row may become "misc_feature", a translated protein name may disappear, and overlapping features may be merged. Color, arrow style, and note fields are display data; do not treat their absence as sequence corruption, but do not ignore a missing CDS either.

After import, walk the feature table against the source GenBank file, not against memory. Check start and end coordinates, strand, gene or label, and any qualifier the lab uses for product, note, or locus tag. Pay extra attention to origins, antibiotic markers, and inserts, because those features decide later restriction plans.

Rebuild what the importer cannot map. If a custom feature type has no equivalent, recreate it as a documented misc_feature with the original label in the note. Record the mapping rule so the next plasmid is not annotated by taste. ZettaGene supports sequence visualization, plasmid construction, and alignment in Zettalab molecular biology tools, which is useful once a clean GenBank or FASTA file exists. It does not remove the need to compare feature tables by hand on the first batch.

Do not "fix" coordinates to match a figure from an old slide. If the imported coordinates disagree with the source .gb file, trust the source file and investigate the parser. Silent rounding or off-by-one errors on circular maps are enough to move a cut site.

Validate After Import: Sequence Identity and Diagnostic Digest

Validation is the gate between sandbox import and team use. Run two checks on every plasmid that will be cloned from, sequenced from, or sent to a collaborator.

First, compare the imported sequence to the FASTA witness. The strings should match exactly, including length and circular topology if the tools expose it. A single-base insertion at the origin wrap-around is a common import defect and will shift every downstream feature. Alignment tools make this comparison visible; a visual glance at the map does not.

Second, predict a diagnostic digest from the imported map and compare it with an existing gel, or run the digest on the physical stock if the map is newly imported and untrusted. Choose enzymes that distinguish the intended construct from empty vector and from a close variant. If the predicted bands from the new file disagree with the historical prediction from the old file, stop the cutover for that plasmid. Either the sequence changed, a site was lost in annotation, or the original map was already wrong.

Where Sanger or whole-plasmid reads exist, align them to the imported sequence, not to an old screenshot. Document the pass criteria in the project record: exact sequence match, feature table reviewed, digest prediction agrees. Experiment records should cite the file version that passed, so later cloning does not grab an unvalidated import.

Keep the Old Software Read-Only During Cutover

The practical failure in many migrations is parallel editing. Someone updates a feature in the new tool while someone else edits the same construct in the old tool, and neither file is canonical. Keep the old application available, but make its project files read-only for design work. Use it as a viewer and as the source of truth until the new copy passes validation.

Write a short cutover rule: new primers, new assemblies, and new shares happen only in the new system after the plasmid is marked imported and checked. Bug-fix annotation on the old file is allowed only if the change is then re-exported and re-imported. Date that re-export. A read-only old vault is cheaper than a forensic merge of two maps six weeks later.

Do not uninstall the old software on the day of first import. License and viewer access should outlast the migration window, because a parser question may appear only when a rare custom feature is needed. Archive the native files, the GenBank exports, and the FASTA witnesses together, with checksums if the lab already uses them for other research files.

A Practical Sequence for Migrating Plasmid Files

Run the cutover in batches by project, not as a single dump of every historical map. Historical files that will never be cloned again can stay in the read-only archive. Files that are in active cloning must pass the full check.

1. Inventory active plasmids. List construct ID, version, native file, and whether a physical stock exists.
2. Export gb or gbk, fasta, and the native .dna or project file. Store them under the same ID so comparison is possible.
3. Import into a sandbox in the new software. Do not replace the team library until validation is done.
4. Map features and compare sequence identity. Rebuild skipped annotations from the GenBank table, not from memory.
5. Predict a diagnostic digest and, where needed, align sequencing reads. Only then mark the plasmid usable and keep the old file read-only.

Assign an owner for exceptions: features that cannot be mapped, files that fail identity, and constructs whose physical digest never matched any map. Those exceptions belong in the notebook, not in chat. A cloud-based R&D workspace helps when sequence tools and records need to cite the same validated file version, but the scientific checks remain the same in any stack.

FAQ

What plasmid file format should I export before switching software?

Export at least two files for each active construct: a GenBank .gb or .gbk file for the feature table, and a FASTA file as an independent sequence witness. Keep the original .dna or other native map as a read-only archive. FASTA alone is not enough for plasmid work because it does not carry CDS, promoters, or restriction-site annotations you will need on day one in the new tool. GenBank is the usual interchange format between design programs, but importers still differ, so the native file remains the fallback when a qualifier is missing. Name all three with the same construct ID and version before you import anything.

Why did my plasmid annotations disappear after import?

Most importers keep the nucleotide string and only translate feature keys they recognize. Custom types, primer objects, display colors, and some qualifiers have no equivalent and are dropped. Overlapping features may be merged, and circular wrap-around features may shift. Open the source .gb or .gbk file as text and compare each important row to the new feature table: coordinates, strand, and label. Rebuild missing scientific features under a documented mapping rule. Do not assume the new map is complete because the circle looks similar. A missing origin or marker annotation is an annotation-loss defect, even when the sequence alignment is perfect.

How do I check that a migrated plasmid is the same construct?

Compare the imported sequence to the FASTA export and require an exact match, including length. Then predict a diagnostic digest from the new map and compare those band sizes with the prediction from the old map, or with a gel from the physical stock. If sequencing reads exist, align them to the imported file. A construct is not "the same" if the sequence matches but a critical site was lost from the feature table, because later cloning plans will miss that site. Record the three results together: sequence identity, feature review, and digest prediction. Fail any plasmid that disagrees and keep using the read-only source file until the discrepancy is explained.

Should I keep the old plasmid design software after migration?

Yes, keep it as a read-only viewer until the active set has passed identity and digest checks, and until rare files with custom features have been opened at least once. Uninstalling on import day removes the only program that fully understands the native .dna or project schema. Parallel editing is the risk to block, not the presence of the old tool. Set the old project directory to read-only, write new designs only in the new software after validation, and re-export if a genuine correction must be taken from the archive. Viewer access can shrink later; the archived exports should remain.

Can FASTA files preserve restriction sites and CDS features?

No. FASTA stores the sequence and a header. Restriction sites can be recomputed from the string if the enzyme is applied later, but CDS names, gene qualifiers, primer notes, and intended cut-site annotations are not in the file. That is why FASTA is a witness for identity, not the working plasmid map. After a software change, recompute sites on the imported sequence and compare them with the old annotated map. If a site you relied on does not appear, either the sequence changed or the old annotation was a label not supported by the sequence. GenBank is the format that should carry the feature table across the cutover.

Do I need to re-annotate every plasmid after changing design software?

Re-annotate only where the importer failed or where the source file was already incomplete. A full manual re-annotation of a clean GenBank transfer creates new opportunities for coordinate errors. Start with a feature-by-feature comparison: keep rows that match the source table, rebuild skipped scientific features, and ignore lost display styling. Plasmids with heavy custom annotation, or maps that never had a proper feature table, need more rebuilding. Use the first batch to write mapping rules so later plasmids are not each decorated differently. Validation by sequence identity and diagnostic digest still applies, even when you decide not to redraw the entire map.

Conclusion

Migrating plasmid files after a software change is a cutover: export gb, gbk, dna, and fasta, map features, then prove sequence identity and digest prediction before anyone designs from the new copy. Keep the old software read-only until that gate passes. To import annotated sequences and inspect maps after a tool change, use Zettalab molecular biology tools.