Liscaragh Migrate › Help › What we expect from you

What we expect from you

Liscaragh Migrate is a tool you operate, not a managed service. It moves data exactly where and how you tell it to, using your own accounts and permissions. That makes a handful of things your responsibility before you run it, not the tool's. This page sets them out in plain language. The EULA is the binding version; this page explains what it means in practice.

The on-screen acknowledgement

Before the first Migration Job on any job you create, the tool stops and asks an Authorised Operator to confirm, on the Customer's behalf, five things:

1. Authorisation

   You are authorised to migrate the relevant data from the source service to the selected Microsoft 365 destination.

2. Destination backup

   The destination has an appropriate backup or recovery method.

3. Backups tested

   Those backups have actually been tested, not just taken.

4. Retention and versioning

   Retention and versioning are enabled where appropriate.

5. Tested first

   The migration has first been tested on non-production data.

It is shown once per job. Once given, it is remembered for that job and does not reappear for it. It applies before anything that moves data, an upload, a Sync, a rerun of failed files, or arming a scheduled migration, and it is never shown for a Preview or a read-only check, since neither of those write anything.

The checklist is deliberately brief. It is a confirmation prompt, not the full list of your obligations: everything on the rest of this page continues to apply in full whether or not it is repeated on screen. A job's settings can disable the prompt, but doing so does not remove any of these responsibilities. It only removes the on-screen reminder, and shifts full responsibility for making these checks onto whoever is running the job.

Backups: both ends, not just one

Maintaining complete, current, independent and recoverable backups is a condition of using the product, not an optional precaution. It covers both sides of the migration:

Source

A complete backup or recoverable copy of the relevant source data, independent of the migration itself, that the migration cannot overwrite, modify, expire or delete. You should be able to restore from it, and you should have actually confirmed that you can, not just assumed it. Source-side retention, versioning and deleted-item recovery should stay switched on until the migration is validated and business has signed off.

Destination

An appropriate backup, recovery point or rollback mechanism for the destination too, alongside SharePoint's own versioning and retention settings, checked and set appropriately before you start. You should understand what the destination's recycle bin and retention limitations actually are, rather than assuming SharePoint's defaults cover you, and you should keep a record that lets you tell existing destination data apart from what the migration adds.

A backup that exists but has not been verified does not count. Verification means confirming the backup actually contains the right data, is complete, does not depend on the same system that might cause the loss in the first place, can be reached by the people who would need it, and can be restored within a timeframe you would actually accept.

Version history and retention, specifically

This is called out on its own because it is easy to overlook and one of the five points on the on-screen checklist: SharePoint document libraries and OneDrive do not always ship with version history configured the way you expect, and retention policies are a tenant-level and site-level setting, not something the migration itself controls. Check versioning is switched on, and that retention is configured appropriately, on the destination before you migrate, not after something needs recovering.

Test migrations, before production data at scale

Before you run a migration against production data in bulk, complete a representative test using non-production data or a genuinely representative, controlled subset of it. A useful test covers, where relevant to your data: a range of file types and sizes, realistic folder depths and path lengths, real metadata and permissions, likely naming conflicts, any content types the destination might not support, and the error conditions you would expect to hit for real. A test run against three tidy files in an empty folder does not tell you what a real migration will do.

Permission to access, alter and use both APIs

You are responsible for confirming, before you connect anything, that you: own the data or hold every permission, licence and lawful authority needed to access, copy, transfer, modify, store and migrate it; have the authority to grant access to both the source and destination environments; and hold, and will keep holding for as long as you use the product, whatever agreement, registration or authorisation each third-party provider, Datto Workplace and Microsoft 365 among them, requires for your access to and use of their APIs, including where that access happens through this tool.

In practice this covers permission to alter both ends (the destination is written to; some source-side renaming decisions are made for SharePoint compatibility, recorded in the report), and permission to use the Datto Workplace API and the Microsoft Graph API under each provider's own terms, not just permission to use the data itself.

The wider list

Backups, testing, versioning and API permissions are the items worth a page of their own, but the EULA's Customer Responsibilities clause is broader: it also covers things like scoping the migration, destination structure and information architecture, user and permission mapping, malware scanning, API and bandwidth limits, scheduling, reviewing logs and failures, cutover planning, and deciding when it is actually safe to proceed. Liscaragh Software does not make any of those decisions on your behalf. Read the EULA in full, particularly clauses 7 to 10, for the exact wording.