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: assess what you actually have
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.
Picking the right platform
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 digital 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 realising 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 coloured 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.
Compliance during migration: what actually matters
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.
Common questions
How long does the transition from paper lab notebook to an ELN actually take?
The short answer is: longer than the software setup, but shorter than most labs fear - if you're prepared. A modern, intuitive ELN like IGOR can have your team set up with a customized workspace and ready to log their first experiments within a few hours. Initial training, when paired with good documentation, can also be completed relatively quickly. So technically, you could be up and running within a few days.
What actually takes time is everything around the software. How should the workspace be structured to best fit your team's needs and workflows? What naming conventions make sense? What historical data needs to come across, and what can get archived? These decisions involve people, opinions, and competing priorities, and they take as long as they take. On top of that, most labs transitioning from paper don't have their data and inventory in anything close to a usable format. Getting it collected, organized, and complete is usually what takes the longest.
For a small lab with straightforward workflows and not much legacy data to deal with, a few weeks to a couple of months is realistic before the system is genuinely part of daily life. A fuller transition - covering template design, permissions, migration decisions, inventory cataloging, and genuine team-wide adoption - is more realistically a three-to-six month project, sometimes longer, especially if validation and regulatory requirements come into play.
Can we migrate while running normal lab operations?
Yes, and in our experience, the labs that handle the transition best are the ones that don't treat it as a discrete “everyone switches on Monday” event at all. There's no hard stop on using paper and the old system when people start using the ELN; there's a transition period, and planning for that honestly makes everything easier.
What that typically looks like: new experiments go into the ELN from day one, while ongoing work continues as normal. You're not stopping the lab to digitize everything at once - you're running a hybrid period where the old and new systems overlap, and that's completely fine. Start with one team or one workflow, get them comfortable, work out the inevitable kinks in your templates and naming conventions based on real use, and then expand. It's slower than a hard cutover, but the adoption tends to stick.
The one thing to plan for honestly is that the first few weeks will be a little slower than usual. Logging that first day's experiments will take longer than it would on paper, simply because people will have questions mid-experiment, and need to find their way around the new system. Someone will set something up slightly wrong and need help fixing it. None of that is a crisis, but it does mean you should avoid scheduling the go-live immediately before a critical deadline or a particularly intense period in the lab.
The other thing that makes or breaks a phased migration is how quickly frustrations get resolved. If someone hits a problem and it takes a week to get an answer, they'll get frustrated and come up with workarounds - which is why fast, accessible support in the early weeks is important. Most labs underestimate the importance of good customer support and accessible self-help documentation when comparing vendors, but it should be pretty far up your list. It's what determines whether people actually adopt the system or just tolerate it.
Should we migrate everything, or just recent data?
In our experience, migrating everything is rarely the right call - and it's one of the decisions that adds the most unnecessary time and effort to a transition.
The more useful question is: what data are you actually likely to need in the new system? Active projects, protocols still in use, samples and reagents still in circulation - that's your priority. Completed studies from several years ago are a different matter. Unless you have a specific reason to expect you'll need them actively - a follow-up study, a regulatory audit, a paper revision - re-entering old notebook pages is a significant effort for limited day-to-day return.
A simple tiered approach works well: recent and active work gets migrated properly, older completed projects get archived in an accessible format but aren't necessarily re-entered in full, and anything in between gets assessed and migrated as it becomes relevant. That way, historical data (if truly important) will get migrated naturally over time - when an old protocol gets revived, when a sample set gets reused, when a new team member needs context on a previous project.
For regulated labs, retention requirements set a floor on how long data needs to remain accessible, but they don't require everything to live in the active system. Let your regulatory obligations inform your archiving decisions rather than defaulting to migrating everything just to be safe.
How do we make sure nothing gets lost?
The single most important thing you can do is keep the original records intact and accessible throughout the process. So back everything up before you touch a single record - multiple copies, stored in different locations.
Don't discard paper notebooks, don't delete spreadsheets, don't archive drives somewhere difficult to reach. They're your safety net, and you want them close until you're certain you no longer need them. For regulated labs, the originals may need to be retained regardless - but even for labs without that obligation, holding onto them costs nothing and has saved more than a few headaches.
Beyond that, a few practical habits go a long way. As data gets entered into the new system, spot-check it against the source: not every record, but enough to catch systematic errors early. If you're doing any bulk imports from spreadsheets, verify the record counts before and after. And if you're digitizing paper records, the dual verification approach - one person transcribes, a different person reviews - gives you a documented check that what went in matches what was on the page.
The labs that lose data during migration almost always do so because they moved too fast and retired the old system before the new one was properly validated. Build in an overlap period, be conservative about when you declare the migration complete, and you're unlikely to have a problem.
