Transition from another ELN to SciNote
5 min read
Transitioning from one ELN to another includes strategic decisions on project management during the switch, data access as well as data migration. Understanding the options available can help you make an educated choice for your organization.
Options for a transition between systems
The transition from a previous ELN system to SciNote can seem like a daunting task albeit straightforward. On the contrary, the transition process has more than one scenario option an organization can choose.
The task, however, does not need to be daunting at all.
SciNote support team will be able to help you with guidance as well as support through the process itself. Should you have a previous system provider, it is as important to also have the information or assistance from their end on how your data can be accessed or exported from the old system. This can determine which scenario of transition and data migration is the optimal choice.
The transition can be a clean-cut break from the old system or alternatively, a gradual shift:
1.) A clean-cut would mean that from a defined date onward the old ELN system would not be used anymore and all projects, data and processes would be managed and tracked exclusively with SciNote.
2.) A gradual approach plans for a period of time, when the old and the new ELN systems both operate. This means the open projects that were started in the old system, are managed there until they finish/close, whereas new projects are created and managed exclusively with SciNote. In this way, the gradual shift between the systems is achieved and is concluded once all the projects managed in the old system are closed.
An important decision has to be made no matter which transition approach the company chooses. This is with regards to the access of the legacy data and whether this too has to be migrated to SciNote in its entirety. The most elegant option is to identify the specific data that needs to be migrated or at least accessible and what data can be left for archiving.
Once this is clear, the technical execution takes place, which is, as mentioned above, dependent on how accessible is the data in the old system.
Are you considering switching to SciNote?
Learn how SciNote can cover your lab’s needs.
How to transition to SciNote
Migrating between two systems will often require migration of at least some of the data.
The absence of data standardization makes every transition between two systems challenging. Somehow humans are not good at unifying standards. For example, there is no single standard for basic things such as electrical voltage or electrical plugs therefore we have to rely on travel adapters.
When it comes to data there is even less standardization and we often need to develop custom “data adapters” (data migrations) on the fly. Often times digital tools that store our data in databases to which end users either do not have access or the underlying data models are too complex to understand or are proprietary.
Therefore, when we need to migrate data between two tools, from example from a previous ELN to SciNote, we often rely on the export capabilities of the old tool and import capabilities of the new tool.
The steps described below will give you an overview of the data migration process and will help you understand why is it not always as straightforward as you might have imagined in the first place:
1.) Check the export capabilities of the old system
Most of the software systems generate some sort of data export. Ideally, the export should be in a structured data format, such as a csv table or a series of csv tables. Unstructured data exports such as pdf reports are extremely challenging to migrate.
2.) Map the data objects in your old software solution and SciNote
In this step, you will need to understand how your data was organized in the old software system and how it will be organized in SciNote. Due to the lack of data standardization, the information will most likely be organized in a different way, despite the fact that the two tools serve the same or very similar purpose. For example, you will need to determine which pieces of data (objects) from the old system will map to a Task, which to an Experiment or a Project, and so on. You will most probably need to go even deeper into mapping strategy as some objects can be more complex. For example, you will need to determine what represents the title of a Task, what represents the Description of a Task, etc.
3.) Find incompatibilities between the systems and prepare a resolution strategy
Sometimes you will find out that SciNote does not have an appropriate place to store some piece of data. Or you will determine that the title for a Protocol in SciNote allows fewer characters than the old system. You will need to prepare a list of such incompatibilities and for each a resolution. For example, you may decide to attach a piece of data to a different field or simply cut the name of the Protocol.
4.) Build a script to execute the migration
In case you need to migrate large amounts of data it makes sense to develop a data migration script that will automate this step.
5.) Execute the migration script.
6.) Verify that the data was transferred correctly
Perform validation to ensure that data was transferred correctly and that SciNote functions correctly with the migrated data.
There is always the possibility of manual data migration. In this case, you will still need to execute steps 1 to 3 and then transfer data manually. Manual data migration might sound very daunting and labor-intensive; however, it is a valid option when you need to migrate a limited amount of data (e.g. just the work in progress).
You can also schedule a Q&A session with a key account manager to discuss the best option for your lab.