The credentials a migration tool never needs to hold
Every migration tool needs permission to read data from one system and write it into another. The important question isn't whether the tool needs credentials. It's where those credentials live after you've entered them.
Many cloud-hosted migration and backup platforms require credentials or long-lived authentication tokens to be stored within infrastructure operated by the vendor. Liscaragh Migrate was designed differently. The software runs on a machine you control, and the credentials it uses remain there too.
The model many tools use
Running migrations from a hosted service is a perfectly valid architectural choice. It allows the vendor to manage the infrastructure, schedule jobs centrally and provide web-based dashboards.
It also means the vendor becomes part of your security boundary. Whether credentials are stored directly or represented by long-lived authentication tokens, your organisation is placing trust in another environment to protect privileged access to your data.
For organisations assessing supplier risk, that's an important consideration. Frameworks such as NIS2 place increasing emphasis on understanding the security posture of suppliers that have privileged access to critical systems. Where credentials are stored, who controls them and how they're protected are all sensible questions to ask before authorising any migration.
A different approach
Liscaragh Migrate runs locally on a Windows device under your control. Data moves directly between your source platform and Microsoft 365. Nothing is routed through Liscaragh infrastructure, and there is no Liscaragh-operated service that stores working credentials for your environment.
If our infrastructure were compromised, there would be no customer credentials there to retrieve because they were never sent to us in the first place.
How credentials are handled
Depending on the source platform you're migrating from, Liscaragh Migrate may use up to three different types of credentials. Each is protected using Windows' own security mechanisms rather than a custom credential store.
Microsoft 365
Microsoft 365 connections use certificate-based authentication rather than stored passwords.
During setup, the wizard generates a certificate locally on your machine. The private key is stored in the Windows Certificate Store and marked as non-exportable. Only the public certificate is uploaded to your Microsoft Entra app registration.
There is no password to store or recover. Even if someone copied the application's configuration files, the private certificate key remains protected by Windows and cannot simply be transferred to another device.
Datto Workplace
Datto Workplace client secrets are encrypted using Microsoft's Data Protection API (DPAPI).
DPAPI ties the encrypted data to the Windows user account that created it. The client secret is never stored as plain text and is only decrypted when required to authenticate directly with the Datto Workplace API.
Copying the application's configuration folder to another machine does not provide a usable credential because the encryption is bound to the original Windows account.
Network shares
When a migration requires separate credentials to access a network share, Windows Credential Manager is used.
The password is stored by Windows itself, not by Liscaragh Migrate. The application never exposes the stored credential. Windows automatically presents it when required, including during scheduled overnight migrations.
Why this matters
Keeping credentials on the machine performing the migration reduces the number of places they can exist.
There is no vendor database containing customer credentials. There is no cloud vault operated by Liscaragh Software. There is no administrative portal where our staff could retrieve a customer's working Microsoft 365 authentication.
That doesn't eliminate every security risk, but it removes an entire class of exposure by avoiding central credential storage altogether.
The trade-off
There is a trade-off, and it's worth stating openly.
Because Liscaragh Migrate never stores a copy of your credentials, it cannot restore them for you.
If you rebuild the migration workstation, you'll run the setup wizard again to generate a new Microsoft 365 certificate. If you move the migration to another computer, you'll authenticate again on that machine.
That's an intentional consequence of keeping the credentials under your control rather than ours.
Even support follows the same principle
When you choose Help > Email support, Liscaragh Migrate automatically removes API secrets, access tokens and refresh tokens from the diagnostic package before it's created.
Support information is collected without including the credentials used to perform the migration.
See exactly how each credential is handled
The full breakdown, including how the Windows Certificate Store, DPAPI and Credential Manager are each used, is in the credential storage guide. Or see the wider picture in security and data handling.
Good security still starts with you
Local credential storage doesn't replace good identity management.
Migration accounts should still follow the principle of least privilege, be scoped only to the permissions required for the job, and be disabled or removed once the migration has completed.
What this architecture does is reduce the number of places those credentials can be exposed.
The question worth asking
Cloud-hosted migration platforms aren't inherently insecure, and many reputable vendors protect customer credentials to a high standard.
But it's still worth asking one simple question before authorising any migration tool: where will my credentials live once I've entered them?
For Liscaragh Migrate, the answer is straightforward. They remain on the machine you control, not in infrastructure operated by us.