Here's something worth admitting out loud: most labs know they have a documentation problem long before anyone does anything about it. You know the protocol binder hasn't been updated since the person who put it together left. You know the cell line database is an Excel file on a shared drive that three people have edit rights to and everyone manages slightly differently. And you know that if the lab manager got hit by a bus tomorrow, half (or more) of what the lab knows about its own samples and operations would go with them.
The system works, in a sense. It's just that "works" means "hasn't catastrophically failed yet."
What usually breaks the stalemate and has research teams switching to an electronic lab notebook is something concrete and embarrassing. Like a collaborator asking for raw data from a study you published 18 months ago and you spending the better part of a week emailing people who've since left, digging through archived drives, and eventually reconstructing results from intermediate files because the originals were on a computer that's no longer in service. Or you're six weeks into a project and discover that two people have been running slightly different versions of the same protocol because one person updated the SOP in their copy, but the rest of the team didn’t know.
This guide is for labs that are past the "should we migrate?" question and into the harder one: how do you actually do it without losing data, derailing ongoing work, bankrupting your organization, or spending six months on a project that was supposed to take six weeks or less.
Before you start: what do you actually have, and what is worth migrating?
Before migrating lab data from paper to an ELN or LIMS, take stock of what records your lab has, where each type lives, what format it is in, and which of it is worth bringing across.
The instinct is to jump straight into evaluating platforms. Resist that. Product demos are good at dazzling you with features your team will never use, while glossing over whether the platform can actually handle your team’s research workflows, or the data formats coming off your instruments. A talented salesperson will have you excited about their newest AI agent long before you've checked whether the system can store files from your MassSpec. Spend a few weeks understanding your existing data and what your team actually needs before you start comparing vendors. It pays off considerably later.
Start with a realistic file and document inventory. What do you have, and where does it live? Experimental records, raw instrument data, SOPs, sample and reagent information, project documentation - each of these may exist in different formats and different locations. Some of it will be well-organized. A lot of it probably won't be.
Then the harder question: what's actually worth migrating?
Not everything in your legacy system needs to come across. Active projects from the past two or three years - yes, migrate those, or at least the most important experiments and data. Completed studies from 2016 that no one has opened since publication? Archive them somewhere accessible and move on. Trying to migrate everything is how go-live dates slip by months.
Some labs take a simpler approach: a clean cutoff date, with everything going forward into the new system and legacy data staying in whatever format it was created in. Whether that works depends on how important it is to your team to have historical data searchable and connected to current work. There's no universal answer, but it's worth pausing on the question before defaulting to "migrate everything" - because that choice has a real cost in time and effort, and most labs overestimate how often they'll actually go back to old data.
Also assess data quality honestly. An entry with no date, poorly described methodology, and incomplete data doesn't become clearer when you move it to a new system - it just becomes a searchable mess instead of a paper one. Migration is a good opportunity to document what exists and flag what doesn't, but the new system won't make people document better on its own. The switch to a new system is one of the few moments when people are genuinely open to doing things differently. Don’t waste that opportunity. Agree on what a complete notebook entry actually looks like in your lab (our lab notebook best practices guide is a good starting point), set up standardized experiment templates for people to use, and build some structure around how research data moves through your workflows. Get the structure right upfront and good documentation habits will follow. If the template asks for it, people fill it in.
How do you pick the right platform for a migration from paper?
For a migration from paper, the right ELN or LIMS lets your team import its own spreadsheets and documents and lets you configure the workspace around how your lab is organized. For regulated work, the platform also needs audit trails, version control, entry locking and electronic signatures built in.
There are a few things that actually matter when you're evaluating an ELN or LIMS for migration purposes, beyond the usual feature list.
Most vendors will offer to handle your data migration for you, which sounds convenient until you see the invoice. Smaller labs especially tend to handle it themselves because of budget constraints, and that means the platform needs to make self-service import actually workable. Can you paste SOP content directly into the system without reformatting everything? Does it accept bulk inventory uploads from an existing spreadsheet? What about proprietary instrument formats - can those be uploaded to notebook entries, or do they need to be converted first? If the system can't handle your data types, you end up either paying the vendor anyway to make it work or accepting that chunks of your data stay outside the system indefinitely, which defeats the point of migrating in the first place.
Structure matters too. Some platforms are rigid about how experiments, samples, and projects need to be organized. Others let you define metadata fields and workspace structure to match how your lab actually works. If you have to completely redesign your workflows to fit the software, adoption will be a slow and painful process (or fail entirely).
That’s why when we designed IGOR we made sure that each team within an organization is able to configure their own workspace - how experiments are organized, what metadata gets captured, how inventory is structured - through the interface, without needing coding skills or vendor support. During a migration that's genuinely useful, because you can shape the new system around how your data is actually organized, rather than translating everything into a fixed schema someone else designed. And if your setup needs to change six months later because a project evolved or a new research area came in, you just change it.
And for labs working under GLP, GMP, or FDA 21 CFR Part 11, the compliance question should come before the feature comparison. Version control, audit trails, entry locking, compliant electronic signatures, access control - a platform that doesn't have those shouldn’t make your shortlist. Check the ELN/LIMS data security and compliance documentation carefully, and ask for specifics rather than taking "we're compliant" at face value.
The migration itself: a realistic walkthrough
How much of this you handle yourself depends on budget, data volume, and the platform you choose. It's worth understanding both paths before committing to one.
Vendor-performed migration
Most ELN and LIMS vendors offer a managed migration service, but 'managed' doesn't mean hands-off on your end. The vendor comes in without knowing your team, your data, or how your research and inventory are organized. That context has to come from you, and they'll be asking for it throughout the process.
If you're migrating from spreadsheets, Word documents, Google Docs, shared drives, and paper notebooks, the path is generally straightforward for the vendor to handle technically. The complexity usually comes from the decisions and mapping, not the transfer itself.
How well you plan on your end determines whether the migration runs efficiently or accumulates unnecessary costs. Billable hours spent re-mapping data after a misunderstanding add up quickly. Before the vendor starts work, get a few things in order.
That starts with getting the whole team to map out where your data actually lives, what formats it's in, and - more importantly - what genuinely needs to come across. Selectivity in what actually needs to be migrated versus what can be archived or left behind is the biggest lever you have on both time and cost. Data tends to be more scattered than anyone realizes until they start trying to move it. If paper notebooks are part of what's being migrated, your team will need to digitize them first - the vendor usually doesn’t do that for you. Agree on a consistent format for the resulting files (PDF, labeled with date, author, project, and experiment title works well) and keep a spreadsheet that maps each file to the relevant raw data, protocols, and inventory items it belongs to.
At some point you'll probably think: this sounds like our team is going to do most of the work - what are we actually paying the vendor for? And honestly, you wouldn't be entirely wrong. There's no way around the fact that a data migration is a significant investment of your team's time, because only your team really knows your data. Hand a vendor your paper notebooks, hard drives, and spreadsheets and they can't tell you which inventory items belong to which notebook entries, or which version of a protocol was actually used. That mapping has to come from your team.
What that mapping looks like in practice is a document - usually a spreadsheet - that shows how every field in your old system translates to its equivalent in the new platform. The vendor will tell you what fields the new system expects. Your team tells them what the data contains and how it should be matched. Get that right before anything moves. What the vendor then handles is formatting your data correctly and loading it into the system so it's available and searchable from day one.
Before committing to a full migration, run a pilot with representative sample datasets. Choose a mix of simple and complex records, including some with known relationships - experiments linked to inventory items, for example. Check that those relationships transfer correctly, that attachments are accessible, and that dates, numbers, and text all appear as expected. Have actual lab users review their own data; they'll catch things that project managers and IT staff won't. Document every problem found and how it was resolved.
Once the pilot is validated, decide whether to migrate in phases by project or data type, or move everything at once. Phased approaches carry less risk and let you learn from each batch. A complete migration gets everyone onto the new system faster but requires more coordination and a higher tolerance for launch-day friction.
If you handle it yourself
For most labs, the self-managed migration is less a technical data transfer and more a managed transition. New work goes into the new system from day one, historical data follows gradually as it becomes relevant, and the team builds familiarity along the way. It's slower to complete and faster to start, and the process stays in your hands throughout.
Phase 1: Set up before anyone starts
Most of the meaningful work in a migration happens before the first experiment gets logged. The workspace needs to be configured around how your lab actually works. Configure your inventory setup, define your metadata fields, build experiment templates for your most common protocols, migrate essential SOPs, and establish user roles and permissions according to your team members' roles and responsibilities. None of that takes long if the right people are involved in the decisions: the lab manager who maintains the inventory and handles lab operations, the PI who understands what will need to be auditable down the line, the bench scientist who can tell you whether a proposed template actually reflects how experiments get documented in practice.
It's worth spending time on this before anyone enters a single record. Realizing you've been using three different naming conventions for the same sample type after fifty experiments have been logged is a fixable problem, but an annoying one.
Make sure to back up all data before the transition starts. Old notebooks, spreadsheets, instrument files. Put a copy somewhere it won't be touched, just in case.
Getting your inventory in order is worth starting before you've even picked a platform. Many labs have no formal lab inventory system, or are working from spreadsheets that haven't been properly maintained in months or years. If you wait until after go-live, your team will be using the new system without being able to properly link experiments to the samples and reagents they're working with - and that connection between bench work and inventory is one of the most valuable things an integrated ELN and LIMS gives you.
So to help your scientists hit the ground running, start building shared spreadsheets during the evaluation phase - one per material or sample type, so things are already pre-sorted when the time comes to import them into dedicated inventory repositories. For each type, agree as a team on what you want to track: item name, catalog number, concentration, passage number, genetic modifications, storage location, quantity, expiry date, who's responsible for it. The fields will vary by material type, and it's worth thinking through what's actually useful before you start, rather than realizing mid-migration that a critical piece of information wasn't captured. If you've already chosen a vendor, ask them whether there are any mandatory metadata fields the platform requires - better to know that before you've built out a dozen spreadsheets.
Spread the cataloging work across the team rather than assigning it to one person. Beyond speed, there's a less obvious benefit: when people have a hand in building the inventory themselves, they're more likely to keep it current once it's in the system. The record becomes something they built and took ownership of, not something handed down.
One tip that sounds almost too simple but genuinely works: keep a roll of colored dot stickers somewhere in the lab. Any item that's been entered into the spreadsheets or the new lab inventory management system gets a dot on the physical label. That way everyone can see at a glance what's already cataloged and what still needs to be added, without checking a spreadsheet or asking around. It keeps the inventory migration ticking along in the background - a little at a time while people have a few minutes during an incubation or while waiting for the centrifuge.
When the time comes to import, most platforms accept bulk uploads directly from CSV or Excel, so the spreadsheet work done during planning becomes the migration data.
Phase 2: Agree on standards
This is the one moment when you have everyone's attention for the housekeeping that usually gets deferred indefinitely. How samples get named, how dates are formatted, which abbreviations are acceptable, how reagent lots get tracked. Decisions made here follow the lab for years, through every search, every report, every time someone tries to interpret a record they didn't create.
If the lab has never had formal naming conventions, now is the time to create them. A few principles that hold up in practice: names should be human-readable without needing a separate key, dates work best in ISO format (YYYY-MM-DD sorts correctly and removes the month-day ambiguity that trips up international collaborations), and experiment titles should describe what was actually done rather than just referencing a protocol number - someone searching the system a year from now should be able to tell from the title alone whether an entry is relevant to what they're looking for.
When an SOP lives as a PDF, the researcher ends up with two things open at once - the protocol in one window, the notebook entry in another - jumping between them as they work. If something doesn't go to plan, the deviation gets noted somewhere in the free-text entry, with no clear connection to the step where it actually happened. With an SOP built directly into the experiment as a fillable template, deviations get captured in context, right at the relevant step, with a full audit trail and version control baked in. When that experiment is reviewed six months later, it's clear exactly what was done, where it diverged from the protocol, and which version of the SOP was in use at the time.
If you're not sure where to start with structuring SOPs for a digital system, our guide to mastering SOP management in the lab covers the practical side of that in more detail. And if SOPs have historically been managed informally, now is a good time to introduce a proper structure and put a real review and approval process in place.
Define what a complete experiment record looks like for your lab. Without that, everyone defaults to their own “system”, which, for most teams, means that three researchers on the same team document the same type of experiment in three noticeably different ways. Settling on a shared standard - how to document objective, method, observations, results, deviations, next steps - is a small upfront investment that will pay off every time someone else needs to understand, reproduce, or audit an experiment.
Phase 3: New work first, historical data gradually
All new experiments go into the system from day one. That's where the team builds confidence, and where the return on the migration investment starts. Historical data comes across as it becomes relevant: an old protocol being revived, a sample set being reused, a project changing hands. Not everything needs to migrate, and trying to move it all at once, or before your team starts using the new system, is usually how transitions stall.
Anything older than a few years that hasn't been referenced since publication probably belongs in an archive - accessible if needed, but not worth re-entering in full.
For inventory: anything new coming into the lab goes into the system before it goes on the shelf. Existing stock gets imported in batches from the spreadsheets built in Phase 1, or as time allows.
A new system is only as good as what goes into it. The first few weeks usually set the tone, and it's worth being deliberate about the habits being established - especially around the timing of write-ups. Entries written during the work capture a different level of detail than entries written at the end of the day, or the end of the week. The reason a concentration got adjusted, what a sample looked like before readout, the equipment issue that might explain an outlier - these details are often the most scientifically important parts of the record, and yet they're exactly what doesn't survive a retrospective write-up. The same goes for deviations: note them as they happen, not after the fact.
And for linking experiments to projects: do it at creation, not later, because later rarely comes. The new system makes all of this easier, but the habit still has to be established.
Phase 4: Go-live and settling in
Training is what separates a migration that sticks from one that quietly unravels over the following months. The goal of the first sessions isn't to demonstrate every feature. It's to get each person confident in the tasks they'll actually do every day: starting a new experiment entry, searching for a sample, updating a protocol. Feature depth comes later; confidence in daily use comes first.
If you're using IGOR, the ELN mobile app is worth covering specifically for bench scientists early during training. Being able to capture a handwritten calculation or photograph a gel at the bench and having it upload directly to the right notebook entry is the kind of easy transition workflow that tends to win people over quickly - because it connects the old way of doing things with the new seamlessly.
Identify a few early adopters or power users within the team - people who take to the system quickly and can answer basic questions from colleagues without everything escalating to the lab manager or a support ticket. Peer-to-peer help is faster and less intimidating than formal support channels, and it builds internal expertise that persists well beyond the migration period.
Keep the old system accessible for the first few months - not as a parallel working environment, but as a reference. People need to know the historical record is still there while they're building confidence in the new one. Knowing they can look something up in the old system if they need to removes a significant source of anxiety about the transition.
In the first weeks, gather feedback actively rather than waiting for complaints. Some friction is normal and resolves as familiarity builds. Other friction could point to genuine problems: a template that doesn't match the actual workflow, a metadata field everyone leaves blank because it doesn't make sense, or a useful feature nobody knows about because it wasn't covered in training. Address those issues early.
What actually matters for compliance during a lab data migration?
For labs operating under GLP, GMP, or FDA 21 CFR Part 11, compliance can’t be a separate workstream - it needs to be integrated into each phase of migration from the start.
In Phase 1, platform selection and workspace configuration need to account for compliance requirements before anything else. Version control, audit trails, entry locking, compliant electronic signatures, and data access controls are non-negotiable. If a platform doesn't have these capabilities built in, it shouldn't make your shortlist regardless of its other features. When configuring user roles and permissions, have your quality team involved from the beginning. Who can create records, who can modify them, who can approve SOPs or witness notebook entries - all of that gets documented as part of the validation package, not sorted out after go-live.
The standards and naming conventions your team agreed on in Phase 2 become part of your controlled documentation. SOPs loaded into the system need version control from day one and a defined process for how they get reviewed, and how updates get proposed, approved, and communicated. If your lab has previously managed SOPs informally, migration is the moment to formalize that process properly.
In Phase 3, when historical paper records are being digitized, the process of transcription itself becomes a regulated activity. Every record entered into the system needs to accurately represent the original - and that fidelity needs to be documented. The standard approach is dual verification: the person who transcribes a record is not the same person who reviews and approves it. This creates an auditable check that the digital entry matches the source document, and gives you a defensible record of how the data entered the system.
Original paper records should be retained - not discarded once digitized. Depending on your regulatory environment, the paper originals may remain the primary record for a defined period, with the electronic version serving as a working copy until your validation is complete. Confirm this with your quality team before the digitization process starts.
Where paper records carry handwritten signatures - signed protocol approvals, witnessed observations, supervisor sign-offs - document how those are represented in the new system. The signature itself can't be migrated, but the fact that it existed, who signed, and when can be captured in the electronic record as part of the transcription process. Your quality team should agree on the approach before anyone starts entering data.
The same principle applies to training records. Before anyone enters regulated data into the new system, there should be documented evidence that they were trained on it - what they were trained on, when, and by whom. Auditors expect this, so build it in from the start.
Conclusion
Moving from paper to an ELN is one of those projects that looks more daunting from the outside than it turns out to be in practice - but it also has a habit of taking longer than anyone initially plans for, usually because the data and inventory side of things is messier than expected, and because the decisions that seem minor (how do we name this? what counts as a complete entry?) have a way of generating more discussion than anticipated.
The labs that come out the other side in good shape tend to share a few things in common: they did an honest assessment of what they actually had before they started, they got the people who would be using the system involved early rather than presenting it as a fait accompli, and they didn't rush to retire the old system before they were genuinely confident the new one was working. The labs that struggle usually either tried to do too much at once, or hit the go-live date and discovered their data was in considerably worse shape than they'd assumed.
What's worth keeping in mind is that the migration itself is temporary - the disruption, the hybrid period, the extra time it takes to log that first week of experiments. What you're left with afterward is a fundamentally different way of working. Experiments that are searchable and linked to the samples and reagents used in them. Inventory that's connected to your notebook rather than living in a separate, outdated spreadsheet. The ability to pull up every experiment that used a particular cell line, or to hand a project to a new team member and have them actually find what they need. Over time, that connectivity changes how quickly your team can move - spotting patterns across experiments, tracking down the source of an anomaly, building on previous work without reconstructing it from scratch first. For most labs, that's a significant return on what is ultimately a one-time investment of effort. The main thing is to go in with a realistic plan rather than an optimistic one, and to start the groundwork earlier than feels necessary.
If you'd like to see how IGOR handles imports, templates and inventory during a transition, book a personal demo.
Important Disclaimer: This post is for informational purposes only and reflects our understanding of publicly available guidance as of the date of publication. It is not legal or regulatory advice. Requirements vary by jurisdiction, product type, and intended use. If you're making compliance decisions, talk to a qualified regulatory professional who knows your specific situation.
Frequently asked questions
How long does it take to move a lab from paper notebooks to an ELN?
Moving a lab from paper notebooks to an ELN usually takes a few weeks to a couple of months before the system is part of daily work, and three to six months for a full transition that covers templates, permissions, inventory cataloging and team-wide adoption. The software setup is the short part. The time goes into decisions about workspace structure and naming conventions, and into getting legacy data and inventory into usable shape, because most labs coming off paper have their sample information spread across freezer box sheets and personal spreadsheets. A lab that logs new experiments in the ELN from day one and brings historical records across as they become relevant has people working in the system long before the migration is finished. Most teams are up and running in IGOR within days or a couple of weeks, depending on team size. The minimum setup is one Collaboration Workspace and one experiment database; SOPs, templates, and inventory can be added over time.
Can a lab keep running experiments while it migrates to an ELN?
Yes, a lab can keep running experiments while it migrates to an ELN, and most transitions go better that way than with a hard switch on a set Monday. New experiments go into the ELN from day one, ongoing work carries on, and the paper notebooks and old files stay available as a reference while the two systems overlap. Starting with one team or one workflow lets you fix templates and naming conventions on real experiments before the rest of the lab joins. Expect the first few weeks to be slower, because logging the first day's experiments takes longer than writing them on paper and people have questions mid-protocol. So avoid a go-live date right before a grant deadline or a big animal study. Quick answers to those early questions matter as much as the software does. Personal onboarding, delivered in several sessions over several days, and ongoing support by email and support ticket are included in every IGOR plan at no extra cost.
Should we migrate all our old lab data or just recent records?
Most labs should migrate recent and active records into a new ELN: current projects and the protocols and samples still in use. Older completed studies can stay in an accessible archive and come across when someone revives a protocol or reuses a sample set. For studies conducted under GLP, retention rules set how long the archive is kept.
How do you make sure no data gets lost when moving from paper to an ELN?
The way to make sure no data gets lost in a paper-to-ELN migration is to keep every original record intact and accessible until the new system has been checked against it. Back up spreadsheets and instrument files in at least two locations before anyone touches a record, and keep the paper notebooks on the shelf rather than in an offsite box. As records go in, spot-check a share of them against the source, and compare record counts before and after every bulk spreadsheet import, because one dropped row is easy to miss in a list of 900 cryovials. For paper pages that get transcribed, have one person enter the record and a different person check it against the original page. Most data losses happen when a lab retires the old system too early, so keep the overlap period long. In IGOR, every save of a notebook entry creates a timestamped version, and earlier versions are retained and can be restored.
How should you scan paper lab notebooks for an ELN?
To scan paper lab notebooks for an ELN, scan each notebook to PDF at a resolution high enough to read small handwriting and faint pencil, usually 300 dpi, and check every page before the notebook goes back on the shelf. Name each file consistently, for example by notebook number, author and date range, and keep a spreadsheet that lists which experiments, protocols and samples each notebook covers, so a scanned page can be found again from the project it belongs to. Scan pages with gels, photos and taped-in printouts in color. Pages with handwritten signatures or witness sign-offs need the same care as data pages, because the signature is part of the record. Where an experiment is still active or likely to be revisited, attach its pages to the matching notebook entry rather than leaving them in a single long file. Keep the paper originals on the shelf until your quality team has agreed what happens to them.
Can you import existing lab data into IGOR?
Yes, existing lab data can be imported into IGOR in several ways, depending on where it lives now. Excel and CSV files import directly into table sections of a notebook entry, and text from Word documents can be copied and pasted into notebook entries. Paper notebook pages can be photographed or scanned and uploaded as PDFs, and a PDF attached to an experiment opens right in the app, so it can serve as the notebook entry for that experiment. Inventory comes in through bulk upload on the Momentum plan, so the spreadsheets your team builds during planning, one per sample or material type, become the upload files. For large inventories held in CSV or Excel, IGOR's team helps you get the data into the upload format, sometimes by writing basic scripts to reformat large data sets. IGOR does not offer a full paper migration service and does not scan your notebooks, but every customer gets migration advice and practical help with the transition.
Can I upload photos of handwritten lab notes to IGOR from my phone?
Yes, the IGOR mobile app photographs handwritten notes or a gel and uploads them to an experiment folder or to general uploads. The app also scans documents as multi-page PDFs of up to 15 pages. The IGOR mobile app keeps nothing on the phone: images stay in the app only until they are uploaded or the app is closed.
