What we do with your data.

DataGrine, Chennai, India, is the controller for the personal data described here: what this website collects, and what a DataGrine account holds about you and your team. For the helpdesk data a customer moves through the DataGrine application, the customer is the controller and we are their processor - the migration section explains that side.

For anything in this policy - a copy of your data, a correction, a deletion, or a complaint - email support@datagrine.com and a person will answer.

When you contact us. The enquiry form asks for your name and work email, and optionally your company, target go-live date, the platforms you are moving between, rough record volume and your message. The free-demo sign-up and the route picker take an email address and the route you chose. Only the name and email are required; the rest you can leave blank, and we will just ask on the reply.

We use it to answer you and to scope the work - steps taken at your request before entering a contract. We also store the browser user agent, the referring page and the time, which is how we tell a real enquiry from a bot; that rests on our legitimate interest in keeping the site usable. If you become a client, the work itself runs on our contract with you.

When you create a DataGrine account. We hold your name, your work email, and either a password - stored only as a hash, never as the password itself - or the Google identity you signed in with. We hold the name of your organisation, the teammates and clients you invite (their email address and the role you gave them, and a record of who invited whom), and the commercial side of a migration: the record volumes we counted, the quote we gave you, the plan you chose and a reference for any payment. We do not take card details on the platform. All of this is needed to provide the service you signed up for, and that is the basis we process it on.

Emails we send. The application emails you to verify your address, to deliver an invitation, and to warn you before a migration is archived. Those are part of running the service and are not marketing; we do not add you to a mailing list because you opened an account or sent an enquiry.

We do not sell your data, share it for anyone else’s marketing, or train AI models on it. Nothing here makes an automated decision about you or builds a profile - an enquiry is read by a person.

Analytics on this website. We use Google Analytics to count visits and see which pages are useful. It sets Google’s cookies (named _ga and _ga_ followed by an id) to tell one visit from the next, and Google keeps that data for the retention period set in our account, at most 14 months. We also use our hosting provider’s web analytics, which counts page views without setting cookies. We do not use advertising cookies, remarketing or cross-site tracking, and we do not sell or share analytics data.

When we ask first. If your browser is set to a European time zone, Google Analytics and the support chat load only after you accept them in the cookie banner, which rests on your consent; and for visits from the UK, the EEA and Switzerland the analytics tag is told to set no cookies until you agree. Elsewhere Google Analytics loads by default, on our legitimate interest in understanding how the site is used. Wherever you are, you can accept, decline or withdraw at any time from Cookie settings at the bottom of every page; declining switches analytics off and removes its cookies. Your choice is kept in your browser’s local storage so we do not ask again.

Other cookies on this website. The booking calendar is embedded from Cal.com and sets its own cookies inside that frame if you open it. The support chat is Intercom’s Messenger, which sets Intercom’s cookies when it loads, as described above; anything you type in it goes to Intercom. Nothing on this site needs the Messenger to work - the contact form and email do the same job.

The DataGrine application sets one cookie of its own, and only when you sign in: it holds your session so you stay signed in, it is readable only by our server and only over an encrypted connection, and it expires after seven days without use. Your browser’s local storage keeps your name, email and which organisation you have open, so the page can draw itself before it asks the server. Both are strictly necessary to run a signed-in service, so the application does not ask for consent for them. Where the support chat is switched on in the application, Intercom’s Messenger sets its cookies there in the same way as it does on this site. If we add anything else to the application, we will say so here first, and ask for your consent where the law requires it.

If you choose Continue with Google, Google tells us your email address, your name and your profile picture, and we store those three things on your account. We ask Google for nothing else - no contacts, no calendar, no files - and we never see your Google password. Google’s own privacy policy covers what Google records about the sign-in. Signing in with a password instead tells Google nothing about your account.

On a migration the relationship is the other way round: you decide what moves and where, so you are the controller and we are your processor, acting on your instructions. That is true whether you run the migration yourself in the DataGrine application or our team runs it for you - the managed service runs on the same application, under the same rules. Our data processing agreement applies to every migration, names the sub-processors involved, and we countersign a copy on request.

You connect your source and destination platforms with credentials you provide. We keep them encrypted with a key that belongs to your organisation alone, we use them only over the platforms’ official APIs and only to do the work you asked for, and you can disconnect a platform at any moment, which blanks its credentials immediately. Note that everyone on your team can see the credentials you have connected - we do not yet restrict that to owners and admins.

What moves is your companies, contacts, tickets and conversations with their messages and attachments, and your knowledge base. The application keeps a copy of each record as it was read and as it was written, a log of every request it made to either platform, and a record of every write so a run can be rolled back. Attachments are different: the file passes through memory on its way from one platform to the other and is never written to our storage. We do not use any of it for anything else, we send none of it to any AI service, and we never train models on it.

Our staff have no standing access to your migration. If you want help, you grant support access from inside the application, for a fixed number of hours, to one migration; you can revoke it early, and every time it is used is written to an audit log you can ask us for. On a managed migration only the engineers on your project work in it. If something goes wrong, we tell you without undue delay and within 72 hours of becoming aware so you can meet your own notification duties.

We use a small number of service providers to run the site and the application, and to reach you:

• Hosting, and the databases that store enquiries and everything the application holds.
• Email delivery, so your enquiry reaches us and our verification, invitation and warning emails reach you.
• Google, if you sign in with Google; and the font service that serves the application’s typeface, which sees your browser’s address when it does.
• The support chat, when it loads.
• Analytics: Google Analytics and our hosting provider’s web analytics, as described under cookies.
• An internal notification tool, which tells us an enquiry arrived.
• The booking calendar, if you use it.

They process it on our instructions and for no purpose of their own. On a migration, your own source and destination platforms also handle the data - you already have your own relationship with those, and they are your processors rather than ours. The providers we use are named in the data processing agreement, and we will tell you before that list changes. Otherwise we do not share your data with anyone, and we disclose it to authorities only where the law requires it.

Enquiries, demo sign-ups and route requests are kept for 24 months from our last contact with you, then deleted. Where an enquiry became a project, the records belonging to the engagement are kept for as long as our agreement and our tax obligations require. You can ask us to delete an enquiry sooner and we will, unless we are required to keep it.

A migration has one lifecycle, and it is the same whether you or we ran it. It stays active for 7 days after its first completed full run, which is the window for checking the reconciliation report against the copied data and fixing anything flagged. We email you 2 days before the end of it. The migration is then archived - hidden from the list, but restorable, with its data intact - and 30 days after that it is purged. The purge deletes our copies of your records, the before-and-after images kept for rollback, the log of requests we made and the stored credentials. What survives is the migration’s name, dates and counts, the field mappings, the table that pairs each source id with the target id it became, and the audit rows: enough to say what was done. The request log is deleted after 30 days in any case, whatever state the migration is in.

You do not have to wait for that. You can delete a migration at any time from inside the application, and your organisation’s owner can delete the whole organisation once no run is in progress; everything above goes with it. On a managed migration we delete it at handover, unless you ask us to keep it for the reconciliation window. Deleting a migration never touches what was already written into your destination platform; that is what rollback is for, and it is your decision to run it.

Your account is kept for as long as it is open. A teammate you remove is kept as a record of who did what, and nothing more.

Everything travels over encrypted connections. Passwords are hashed, sign-in tokens are short-lived and can be revoked from our side, Google sign-in uses the current OpenID standard, and an address has to be verified before a password account can sign in. Access inside the application is by role, every request is checked against the organisation it belongs to, and a client seat sees a read-only view with no credentials and no raw records in it.

Three limits, stated plainly. Your platform credentials are encrypted by the application itself; the copied records and logs are encrypted at rest by our hosting provider’s storage rather than by us. We do not yet offer two-factor sign-in. And we hold no security certification yet, so we would rather you read this section than a badge.

We are based in Chennai, India, and our providers are hosted in the United States and the European Union. If you are in the UK or the EEA, that means your data is transferred outside it. Those transfers rely on standard contractual clauses, which each provider publishes as part of its data processing agreement, and our data processing agreement, which applies to every migration, incorporates those clauses on the same terms.

You can ask for a copy of what we hold about you, have it corrected or deleted, object to us holding it, ask us to restrict what we do with it, or ask for it in a portable format. Email support@datagrine.com. We answer within a month, we do not charge, and we will not ask you why. Where we rely on your consent, for analytics and the support chat, you can withdraw it at any time from Cookie settings at the bottom of every page; that does not affect what happened before you withdrew it.

Two of those are not yet buttons in the application: you cannot delete your own account or reset a forgotten password from inside it. Email us and we do either by hand, within 30 days. Deleting a migration and disconnecting a platform you can do yourself, and your organisation’s owner can delete the organisation.

If you are unhappy with how we handled it you can complain to your data protection authority - the ICO in the UK, your national authority in the EEA, or the Data Protection Board of India. If your request concerns data we are migrating for a customer, we will pass you to them: they are the controller, and it is their decision to act on.

If we change this policy we change the date at the top. Material changes to how we handle migrated data are raised with affected customers directly rather than left on a page for someone to notice.