Our admin support guides are moving.
We will be updating and maintaining our support documentation for Figshare repository administrators and managers in our support portal as of June 2024. To ensure you are viewing the most up to date content, please visit our support portal and ensure you are logged in with your institution email.
You can find all our updated admin guides in the support portal: https://support.figshare.com/support/solutions
Figshare always recommends that the Customer considers using our batch management functionality, or API, to migrate your own content into Figshare. This gives you full control over transferring your content from a legacy repository that you know best.
However, Figshare understands that not all Customers have the resources to migrate content themselves, so we offer migration support, according to the options and pricing proposal (supplied by Figshare’s Commercial Team).
If you are considering an assisted migration, it is very important that you understand the limitations, responsibilities, and scope of these projects, as detailed below:
Figshare Migrations Team Resources and Timeline Commitments
Figshare does not have a Team dedicated to Migrations. What this means is that our Implementations Team and our Product Developers have to slot migration projects into each team’s primary work, so we cannot commit to a set migration start date and deadline at time of signing a migration SoW. A start date can only be provided once the Customer has covered all steps detailed in customer responsibilities below.
As a result, Migration Projects are not included within an Implementation Project scope and timeline: all migrations have to be scheduled separately, and will likely only be able to start at least 4 months after the implementation project begins (this could be longer depending on the number of ongoing migrations at the time). However, your Implementation Manager can detail the customer responsibilities as a part of your Figshare Implementation project Basecamp and timeline, so that you can start and complete this work as a part of your implementation project. Thereafter, the scripting, test migrations, and production run will depend on our Development Team capacity at the time.
If the Customer has a tight deadline and wants to migrate legacy content into the Figshare repository immediately, we recommend considering migrating the content yourself.
Customer responsibilities (tasks to complete before dates can be agreed)
Before a timeline for scripting and tests can be confirmed, the Customer is responsible for:
- Extracting records (files & metadata), cleaning your legacy metadata, and formatting it according to Figshare’s migration metadata template (the template is provided at the beginning of the migration project, but we can send you an example file upon request)
- Migrations are a great opportunity to review and clean up errors in the metadata from your legacy system. If you choose not to check and clean the metadata, the records migrated to Figshare will be just as inaccurate as the metadata that Figshare receives; Figshare will not be responsible for missing metadata, values migrated to incorrect fields, or cleaning up metadata during migration
- If you decide to clean/update the metadata after Figshare has started scripting your migration, this will cause delays to the provided timeline and may incur additional fees.
- Mapping metadata: if you are unable to format your metadata into the Figshare metadata template, Figshare can use your legacy extract for an additional fee (as this requires more complex scripting). In this case, the Customer is responsible for mapping every field in the extracted metadata file to Figshare fields, using a supplied migrations and custom fields mapping template (the template is provided at the beginning of the migration project, but we can send you an example file upon request).
- Transferring records to Figshare: no work can commence and no timelines will be agreed until Figshare receives the extract (or at least a sample of the extract)
- NOTE: the extract sent to Figshare cannot change later in the migration process. If the format of the extract changes in any way, this entails re-scripting, delays in agreed timelines, and possibly additional fees, depending on the amount of re-scripting
- Fully detailing all migration requirements: it is your content we’re migrating, so you need to detail every requirement on how Figshare should handle the metadata & files
- Think about group display, item versioning, file embargo/access requirements, and any other special logic you want considered (any special logic requested is subject to Figshare’s analysis and decision over whether it can be supported)
- The clearer your requirements are detailed prior to scripting and test runs, the quicker the process will be.
- Confirming account to own migrated items: by default, all items will be migrated into a single account which will have edit access to the migrated items. This can be a shared service admin account, or a personal user account. Please see below for options at an additional fee:
- If you require authors to link to Figshare account profiles, you have to be able to include the institution_user_id (HR feed ID, or SSO ID) in the author field (or an adjacent field) in the legacy metadata file transferred for migration. If this is not possible, authors can only be migrated as free text
- If you require records to be migrated into Figshare accounts for ownership (edit rights) you need to be able to specify the owner (only one account per item) in the legacy metadata file transferred for migration by inclusion of the institution_user_id (HR feed ID, or SSO ID)
- Defining group(s) affiliation: indicate how items should be migrated into (and/or surfaced on) Figshare groups. Group affiliation will need to be indicated in the metadata if items need to be placed in multiple groups
Figshare’s responsibilities once the above are completed by Customer
At this point, Your Migration Manager can compile a scripting task and queue it with the Figshare Development Team. On average the process from scripting to completion is 2-3 months.
The general scope from here is:
- A developer is assigned to the project and needs 2-3 days to review the task and provide an estimate timeline for scripting and test runs
- On average, the scripting can start 2-4 weeks after the Developer is assigned and reviews the task
- On average, scripting takes 2-4 weeks to complete, after which the first test run is done on stage
- If the test run is fine and the Customer reports no issues or concerns, Figshare can schedule the production run 1-2 weeks later
- However, we advise 1-2 months for fixes, updates to scripts, and re-runs, as we’ve never seen a case where no issues are reported.
- The timeline for this depends entirely on the Customer’s requirements being clearly detailed from the start; the more requirements that are raised after the first script and run are completed, the longer the project will take
Post-migration
- Once the production migration run is completed, Figshare will provide you with a list of all items migrated, containing PIDs (handles/DOIs) and the Figshare URLs. This list is usually provided as a csv file.
- The Customer is responsible for resolving all handles/DOIs to the new Figshare URLs
- The Customer is also responsible for redirecting content from the legacy repository URLs to Figshare URLs (if required)
- If you are migrating handles to Figshare and would like Figshare to manage your handle server going forward, Figshare can assist you with transferring your handle server to Figshare. It is important to let us know if you require this, as this process can take 2-4 weeks, with your cooperation, and is also carried out by a different Figshare Team, so it will occur as a separate process and timeline, post migration.
- In this case, Figshare will resolve handle URLs on behalf of the Customer, once the server is transferred
