# ELN Migration SOP Template: How to Create One for Your Lab By the end of this guide you will have a complete, editable standard operating procedure (SOP) for moving your lab's records from one electronic [lab notebook](/knowledge/molecular-biology/lab-notebook) (ELN) to another. You will know how to inventory every record that needs to move, run a pilot migration, verify that nothing was lost, and document the whole process so that an auditor, a collaborator, or a new hire can follow it. You need admin access to both your old and new ELN, a spreadsheet program such as Excel or LibreOffice Calc, Python 3 installed on one workstation for the counting and verification steps, and enough storage on a lab server or institutional drive to hold a full export. An ELN migration is one of the highest-risk routine projects a lab undertakes. The notebook is the legal and scientific record of your work. Losing a page, an attachment, or a timestamp can invalidate months of experiments. A written SOP turns a stressful improvisation into a checklist you can execute calmly. ## What an ELN Migration SOP Is and Why Your Lab Needs One An SOP is a controlled document that describes a process in enough detail that two different people following it will get the same result. An ELN migration SOP covers one specific process: transferring notebook entries, attachments, metadata, and user information from a source system to a target system, then verifying the transfer and retiring the source. Labs write this SOP for three reasons. First, migrations happen rarely, so nobody on the team has done it before, and a written procedure substitutes for experience. Second, many labs operate under quality frameworks that expect controlled documents for data handling. Labs working under FDA oversight reference 21 CFR Part 11 for electronic records and signatures, and labs working under Good Laboratory Practice (GLP) principles are expected to document data transfers in a way a study auditor can review. Third, a written SOP protects the lab when personnel change. The postdoc who negotiated the migration with the vendor will eventually leave, and the SOP is what remains. A migration SOP is different from a general lab notebook template. A lab notebook template defines what goes into an entry day to day. A migration SOP defines how the entire contents of a notebook system move between systems once. You will reuse pieces of your existing notebook conventions inside the migration plan, but the documents serve different purposes. ## Scope the Migration Before You Write the SOP The most common failure in ELN migrations is starting the export before anyone agrees on what "done" looks like. Spend a week on scoping first. ### Build the record inventory List everything that lives in the old system. A typical inventory includes notebook entries, attached files (instrument output, gel images, flow cytometry files), comments, signatures, entry metadata (author, date, project, tags), and user accounts. Count each category. You need these counts later as acceptance criteria. ### Decide what moves and what stays Most labs do not migrate everything. Archived projects from a closed grant may stay frozen in the old system or move to long-term institutional storage instead of the new ELN. Decide now, in writing, which projects migrate, which archive, and which are deleted after a retention period. Put that decision in the SOP with a table of project names and their disposition. This single table prevents most of the arguments that come up mid-migration. ### Run a quick electronic lab notebook comparison If you have not yet chosen the target system, do the comparison before writing the SOP, because the target system's import capabilities shape the whole plan. Evaluate candidate ELNs on the points that actually affect migration: - Supported import formats (XML, JSON, CSV entry bundles, or vendor-specific export files) - Whether attachments transfer with their original timestamps or get re-stamped at import - How user accounts are created (manual, CSV upload, or institutional single sign-on provisioning) - Whether the system preserves or reconstructs audit trails - What the vendor provides in the way of migration tooling or paid migration services - Export capability out of the new system, so you are not locked in again Write one paragraph in the SOP summarizing this comparison and naming the chosen target. Future readers need to know what the alternatives were and why the lab chose what it chose. ## ELN Migration SOP Template Format The following format works for labs of almost any size. Copy the skeleton into a document and fill in your details. Labs in regulated environments route the completed document through their quality system for approval. Academic labs without a formal quality system should still have the PI and one senior lab member sign it, because a signature turns the SOP into a commitment. ``` SOP ID: SOP-IT-004 Title: Migration of ELN records from [Source ELN] to [Target ELN] Version: 1.0 Effective date: YYYY-MM-DD Author: [name, role] Reviewed by: [name, role] Approved by: [PI or lab head, name, role] Review cycle: 12 months or after any migration incident Related documents: Data retention policy, IT access policy ``` Then write these numbered sections: 1. **Purpose.** One sentence. "This SOP defines the process for migrating all active ELN records from [Source] to [Target] with verified completeness and no loss of attachments." 2. **Scope.** What is included (project names or date ranges) and what is explicitly excluded (archived projects, data in other systems). Name the people authorized to perform the migration. 3. **Definitions.** Define every term a new lab member would not know. At minimum: source system, target system, record, attachment, manifest, checksum, dry run, and go-live. 4. **Responsibilities.** Who inventories records, who runs the export and import, who verifies results, who signs off. In a small lab one person may hold three roles, but name the roles anyway. 5. **Prerequisites.** Admin credentials for both systems, storage location for exports, software installed, vendor support tickets opened, and the backup of the source system confirmed. 6. **Procedure.** The numbered steps, covered in detail in the walkthrough below. 7. **Acceptance criteria.** The objective checks that determine whether the migration succeeded. Every criterion must be measurable. 8. **Rollback plan.** What happens if validation fails, who decides, and how long the source system stays available. 9. **Records.** Where the export files, checksum lists, validation reports, and sign-off documents are stored and for how long. 10. **Revision history.** A table of version numbers, dates, authors, and changes. ## How to Create a Migration SOP for Your Lab: Step-by-Step Walkthrough This walkthrough fills in Section 6 of the template with concrete steps, real commands, and expected outputs. Adapt the specifics to your systems. ### Step 1: Generate the record inventory from the source system Most ELNs can export a metadata file or list of entries. If your source system offers a CSV export of entry metadata, start there. If it only offers a full export bundle, work from that. Build a single inventory file that lists every record with an identifier, project, author, and attachment count. Save your inventory as `eln_inventory.csv` with columns `record_id`, `project`, `author`, `entry_date`, `attachment_count`. Then count what you have: ```python import pandas as pd inventory = pd.read_csv("eln_inventory.csv") print(inventory.groupby("project").size()) print("Total records:", len(inventory)) print("Total attachments:", inventory["attachment_count"].sum()) ``` Expected output looks like this: ``` project Enzyme kinetics 812 Nanoparticle synthesis 446 Archive-2023 187 dtype: int64 Total records: 1445 Total attachments: 6031 ``` Write these numbers into the SOP's acceptance criteria section. They are your ground truth. If the target system holds 1,445 records and 6,031 attachments when you finish, the migration passed its first test. ### Step 2: Run a full export and fix it with checksums Export the entire set of records you decided to migrate. Export tools differ between systems, so follow your vendor's documentation, but the verification step is universal. Generate a checksum for every exported file so you can prove later that the files did not change in transit. A checksum is a short fixed-length string computed from a file's contents. If one byte changes, the string changes. On macOS or Linux: ```bash md5sum exports/projectA_2026-11-11.zip > checksums_projectA.txt cat checksums_projectA.txt ``` Expected output: ``` 5d41402abc4b2a76b9719d911017c592 exports/projectA_2026-11-11.zip 7d793037a0760186574b0282f2f435e2 exports/projectA_2026-11-11_metadata.xml ``` On Windows PowerShell, the equivalent command is `Get-FileHash -Algorithm MD5 exports\projectA_2026-11-11.zip`. Store the checksum file with the export. Anyone who wants to confirm the archive is intact can recompute the checksum and compare. Record in the SOP which checksum algorithm you used, because comparing an MD5 value against a SHA-256 value produces a guaranteed false alarm. ### Step 3: Perform a dry run on one project A dry run is a full migration of a small, representative subset into a test space in the target system. Pick one project with a mix of entry types: text-heavy entries, entries with large attachments, and entries with comments. Import it and then compare, field by field, against the source. Check these items on every record in the pilot: - Text content matches, including formatting such as tables and chemical structure drawings - Attachments open and match their original file sizes - Author names resolve to the correct people in the target system - Entry dates show the original dates, not the import date - Tags, project assignment, and any linked entries survived Write down every discrepancy, even cosmetic ones. Chemical structure drawing formats are the most frequent casualty in chemistry and biology labs, because drawing tools do not all use the same file format. If your target system cannot preserve a structure format faithfully, the SOP should specify the workaround, such as exporting structures as images alongside the original files. ### Step 4: Write the acceptance criteria from your measured counts Turn the inventory numbers and pilot findings into measurable pass or fail statements. Vague criteria such as "records transferred correctly" cannot be checked. Good criteria look like this, using your own numbers from Step 1: - Record count in target equals 1,258 (the count of migrating records, excluding the 187 archived) - Attachment count in target equals 6,031 - Every migrated attachment matches its source checksum - Spot check of 25 randomly selected entries by two reviewers finds no content differences - All active lab members can log in and see their own entries on day one Random selection matters. Reviewers who pick their own favorite entries produce a biased check. Use a script instead: ```python import pandas as pd inventory = pd.read_csv("eln_inventory.csv") sample = inventory.sample(n=25, random_state=42) sample.to_csv("spot_check_sample.csv", index=False) print(sample[["record_id", "project", "author"]]) ``` Expected output is a table of 25 record IDs with their projects and authors. Print it, hand it to two reviewers, and have them compare those specific entries across both systems independently. ### Step 5: Execute the full migration during a quiet window ![Flowchart of the migration run from export to sign-off, with decision points at checksum check and count match that send the team to rollback.](/article-images/illustrations/eln-migration-sop-template-migration-gate.webp) Schedule the production migration for a period with low lab activity, often a week between grants or a holiday period. Freeze the source system, meaning nobody can create or edit entries, from the start of the export. Run the export, verify checksums, run the import, and then run the automated counts again: ```python import pandas as pd inventory = pd.read_csv("eln_inventory.csv") post = pd.read_csv("post_migration_counts.csv") source_total = len(inventory[inventory["project"] != "Archive-2023"]) target_total = len(post) print("Source (migrating):", source_total) print("Target:", target_total) print("Match:", source_total == target_total) ``` Expected output: ``` Source (migrating): 1258 Target: 1258 Match: True ``` If the match is false, do not proceed. Open the discrepancy by project, find the missing records, and diagnose before any user touches the new system. ### Step 6: Run a parallel access period, then sign off Keep the source system in read-only mode for an agreed window, commonly two to four weeks in academic labs and longer where regulatory retention rules apply. During this window lab members compare their own recent entries against the new system and report problems. Collect reports in one shared document. At the end of the window, the approver named in the SOP signs a short statement: acceptance criteria met, exceptions documented, migration declared complete. Only then does the lab record the decommissioning plan for the source system, which depends on your institution's data retention policy. ## Key Migration Parameters at a Glance Record these parameters in your SOP before the migration starts. The example values illustrate the kind of specificity the document needs. Set your own values based on your systems and vendor guidance. | Parameter | Example value | Why it matters | |--|--|--| | Record inventory count | 1,258 records | The acceptance criterion for completeness | | Attachment inventory count | 6,031 files | Attachments are the most common loss point | | Checksum algorithm | MD5 or SHA-256, named in the SOP | Mismatched algorithms cause false failures | | Pilot scope | One project, all entry types | Surfaces format problems cheaply | | Spot check sample | 25 entries, two independent reviewers | Detects silent content corruption | | Source freeze window | 48 hours over a weekend | Prevents records created during migration | | Parallel read-only period | 2 to 4 weeks after go-live | Lets users catch problems on real work | | Rollback trigger | Any failed acceptance criterion | Removes judgment calls under pressure | | Export retention | Full export plus checksums kept per institutional policy | Satisfies auditors and retention rules | ## Validation and Sign-Off Validation means demonstrating with evidence, not memory, that the target system holds what the source system held. Your evidence package has four parts: the pre-migration inventory counts, the checksum files, the spot check worksheets with both reviewers' signatures, and the final count comparison. File them together in the location named in Section 9 of the SOP. For labs under GLP or FDA oversight, this package is what an auditor asks for first. For everyone else, it is what you show a collaborator who asks, two years later, whether the 2026 migration lost any data. Labs working with clinical or manufacturing data should also confirm with their quality unit whether electronic signatures must be preserved or re-captured in the target system, because 21 CFR Part 11 expectations for signature integrity are stricter than ordinary research practice requires. Build that requirement into the SOP before the migration, not after. ## Common Mistakes and Limitations - **Skipping the pilot.** Labs that import everything at once discover format problems across the whole corpus at the same time. One pilot project finds the same problems for a fraction of the effort. - **Forgetting attachments in the count.** Record counts can match perfectly while attachment counts do not, because some import tools create an entry shell and drop or delay attached files. Count both, always. - **Assuming timestamps transfer.** Many systems stamp imported entries with the import date. If original dates matter, verify this in the pilot and, if the target cannot preserve them, export the original dates into a metadata file that travels with the records. - **Ignoring user mapping.** A record authored by "j.chen" in the old system may map to "chen.j" in the new one. Without an explicit mapping table, authorship becomes wrong across the entire notebook, which undermines both credit and accountability. - **No rollback trigger.** When validation fails at midnight during go-live, the team needs a pre-agreed rule, not a debate. Write the trigger into the SOP: any failed criterion stops go-live. - **Migrating dead records.** Every archived entry you move is an entry someone must verify. Move only what your disposition table says to move. - **Retiring the source system too fast.** Deleting or losing access to the old ELN before the parallel period ends leaves no way to resolve disputes about record content. Keep it readable until sign-off. - **One limitation to keep in mind:** every migration is specific to the two systems involved, and vendor import behavior changes between software versions. Test against the exact versions you will run, and treat any general guidance, including this article, as a framework to verify against your own pilot results. ## Frequently Asked Questions ### How long does an ELN migration take? ![Timeline of a small ELN migration from scoping week through pilot, production run, parallel access and sign-off.](/article-images/illustrations/eln-migration-sop-template-migration-weeks.webp) Small labs with a few thousand entries typically complete scoping, pilot, migration, and sign-off in four to eight weeks. Larger labs with tens of thousands of records or heavy attachment loads should plan several months, with most of the time spent on scoping and validation rather than the transfer itself. ### Can we migrate without losing signatures or audit trails? Fully preserving electronic signatures and audit trails is possible only when the target system explicitly supports importing them, so ask the vendor this question before selecting the target. Where it is not supported, labs commonly export the signed records and their audit trails as immutable files into long-term storage and re-capture signatures in the new system only where policy requires it. ### What is the difference between a migration SOP and a validation protocol? The SOP describes how the migration is performed, step by step. The validation protocol describes how you prove the migration worked, listing acceptance criteria and the tests that check them. Many labs keep both as sections of one controlled document, which is the approach this template uses. ### Should we migrate everything or only active projects? Migrate active projects and recent work, and archive closed projects according to your data retention policy. Every record you migrate must be verified, so moving records nobody will use again multiplies the validation workload without adding scientific value. ### How do we handle attachments and raw instrument files? Include every attachment in the inventory count, verify each one with a checksum after import, and pay special attention to large instrument files and proprietary formats. If the target system cannot render a proprietary format, keep the original file attached alongside a rendered image or PDF so the entry remains readable even if the originating software disappears. ### Do we need IT or the vendor to run the migration? You need someone with admin rights to both systems, which may be a technically confident lab member for small migrations. Large migrations, unusual file formats, or institutional single sign-on integration usually need the vendor's migration service or your institution's IT group, so open that conversation during scoping, not during go-live week. ### What should a free ELN migration SOP template include? At minimum: purpose, scope, definitions, responsibilities, prerequisites, numbered procedure, measurable acceptance criteria, a rollback plan, a records and retention section, and a revision history. Any template lacking the acceptance criteria and rollback sections will not survive contact with a real migration. ### When should we retire the old ELN? Retire it only after the parallel read-only period ends, all acceptance criteria are met, and the approver has signed the completion statement. Until then, the old system is your reference copy and your only recourse if a discrepancy appears.