The terms for using DataGrine.

These terms cover your use of the DataGrine application and of datagrine.com. By creating an account, accepting an invitation to one, or using the service, you agree to them.

The service is for business use. You confirm that you are acting for an organisation, that you have the authority to bind it to these terms, and that you are old enough to enter a contract where you are. When we say you we mean that organisation, and everyone it lets into its account acts on its behalf.

Our privacy policy and our data processing agreement go with these terms: the first says what we collect about you, and the second forms part of these terms and applies to every migration without a separate signature. If we sign a different written agreement with you - a statement of work, a data processing agreement of your own, a managed-service engagement - that agreement wins over these terms wherever the two disagree.

You need a verified work email address to sign in, or a Google account. Keep your password and any sign-in method to yourself; whatever is done through your account is treated as done by you. Passwords are stored only as a one-way hash, so we cannot read one back, and we will never ask you for it.

Your organisation has an owner, who can add and remove teammates and hand ownership on. Teammates can do everything the owner can on a migration, including seeing the helpdesk credentials the organisation has connected, so invite people you would trust with those keys. A client seat sees a migration’s progress and results and nothing else - no credentials, no record content.

If you think an account, a password or a connected credential has been compromised, tell us at support@datagrine.com straight away and rotate the credential on the platform it belongs to. Sign-in sessions are held on our server and can be revoked from our side.

DataGrine copies a support team’s history from one helpdesk to another. You connect a source and a target platform with API credentials you hold, choose what to move and map the fields between them. The application then reads companies, contacts, tickets or conversations with their messages and attachments, and knowledge-base articles from the source, transforms each record to the target’s shape, and writes it through the target’s official API.

A migration runs in stages, and each one is yours to start:

• A sample run moves a small number of records so you can open them in the target and check the mapping before anything else moves.
• A full run moves everything in the scope you chose. It can be paused, resumed and retried, and a record that fails is reported with the reason rather than skipped quietly.
• A delta run moves what changed in the source since the last completed run, so a team can keep working in the old platform until the day it switches.
• Rollback reverses in the target what a run wrote there: records it created are removed and records it updated are put back to what they held before. Every write is recorded as it happens, a rollback reverses those writes and only those, and it is available until the migration is purged under the lifecycle in the data section below.

We also run migrations for clients as a managed service. Those run on the same application, under the same lifecycle, with the engagement agreement on top.

Authority over the platforms. The credentials you connect must be yours to use, and the reads and writes we make with them are made on your behalf. You are responsible for staying within the terms your source and target platforms set for their APIs, and the application paces its requests inside each platform’s published rate limit so a migration does not exhaust your own quota.

A lawful basis for the data. The records you move belong to your customers and your staff. You decide that moving them is lawful, that you have told the people concerned what you needed to, and that nothing in the source is data you are not allowed to process. We copy what you point us at.

Correct instructions. The mapping, the scope, the filters and the run you start are your instructions to us. If a mapping sends the wrong field to the wrong place, the application will do exactly that, at scale.

Review the sample before a full run. This is the point of the sample run, and it is the check we rely on: a full run started after a sample means you looked at the sample and were satisfied with how the records arrived. Where something cannot travel faithfully - a field the target does not have, an attachment that lands as a file instead of inline - the application marks it on the record, and those marks are there to be read before the full run, not after.

Use the service for migrating your own support data. Do not:

• move data you have no right to hold or to process, or use the service to hide where data came from;
• connect credentials that are not yours, or use another organisation’s account;
• probe, overload, or try to get around the access controls of the application or of the platforms it connects to;
• copy, reverse engineer or build a competing service from the application, beyond what the law lets you do regardless of this sentence;
• resell access to the service without our written agreement.

If we see an account doing any of this we may suspend it while we ask you about it, and we will tell you why.

The price of a migration is quoted from the volume we count in your source, and it is agreed in writing before paid work starts. A quote is for the scope it names; a scope that grows is re-quoted, not silently re-billed.

Today we invoice by hand and you pay by bank transfer to the details on the invoice, within the period the invoice states. We do not take card details through the application. Prices exclude taxes; where a tax applies to what we sell you, it is added to the invoice, and where you are required to withhold tax at your end, you pay us enough that we receive the invoiced amount.

Sample runs and the volume count are free, so you can see what the migration looks like before agreeing to anything.

The data you move is yours, and your customers’. You are the controller of it; we are your processor and act on your instructions. Our privacy policy says what we collect about you, and our data processing agreement - which forms part of these terms, applies to every account from the first migration, and which we countersign on request - sets out the processing in detail and names every sub-processor. Nothing you migrate is used for anything except your migration, and none of it is sent to an AI model.

A migration has a fixed life in the application. It stays active for 7 days after its first completed full run, and we email the person who created it 2 days before that ends. It is then archived: hidden from the list, but restorable with everything intact. 30 days after archive it is purged. The purge deletes every copy of your records we pulled, transformed or wrote, the record images the rollback ledger kept, the request and response logs from the platform APIs, and the credentials you connected. What remains is the shape of the work: the migration’s name and dates, its counts, the field mappings, the map of source ids to target ids, and the audit entries. API logs are in any case deleted 30 days after they are written, whatever state the migration is in.

You do not have to wait for that. You can delete a migration from the application at any time, and your organisation’s owner can delete the whole organisation once no run is in progress; everything above goes with it. Disconnecting a platform erases its credentials immediately. Deleting a migration does not touch what has already been written into your target helpdesk - that is your data on your platform, and reversing it is what rollback is for.

A migration we run for you as a managed service follows the same lifecycle. At handover we delete it, unless you ask us to keep it for the reconciliation window, in which case it runs out under the schedule above and you get written confirmation when it is gone.

We will run the service with reasonable skill and care, act on your instructions and no one else’s, and tell you without undue delay - and within 72 hours of becoming aware - if something goes wrong with your data. Our staff have no standing access to your migration: if you want us to look at one, you grant support access in the application for a period you choose, you can revoke it at any time, and every use of it is logged.

We do not control the platforms we connect to. A source or target can refuse a record, change what its API accepts, rate-limit us, or store a value differently from how it was sent, and when it does the application reports it per record rather than pretending it did not happen. We do not promise that every record, field or attachment will arrive exactly as it left, and the sample run exists so you can see what arrives before you commit. Your review of it is the acceptance point for the mapping.

We do not promise that the service will be available without interruption or free of defects, and we do not yet offer a written uptime commitment. Where we have made a mistake we fix it, and where a run has gone wrong the rollback is there to put the target back. Beyond what this section says, the service is provided as it is, and we make no other warranty the law lets us leave out.

You can stop using the service whenever you like. Deleting your migrations and your organisation is in your hands, as the data section says. To close your own user account, email us; we do it by hand today, within 30 days, and the privacy policy says what remains afterwards.

We can suspend an account if it breaks the acceptable-use rules, if an invoice is well overdue, or if we have to in order to protect the service or the platforms it connects to. We tell you why, and we lift the suspension when the reason is gone. We can end the service for an account on 30 days’ written notice, or at once if the breach is serious and not put right after we have asked.

When the service ends for you, your data follows the lifecycle above, or is deleted sooner if you ask. The sections on confidentiality, liability, and governing law survive the end of these terms; so does your obligation to pay for work already done.

The application, its connectors, mapping logic and this website belong to DataGrine. You get the right to use the service for your migrations while these terms are in force, and nothing more is transferred. Feedback you give us we may use to improve the service, without owing you anything for it.

Your data stays yours. We take no rights in it beyond the permission to process it for your migration. The helpdesk platforms named on this site are trademarks of their owners; naming them says what we move data between, not that we are affiliated with, endorsed by, or acting for any of them.

Each of us keeps the other’s confidential information to ourselves and uses it only for the work these terms cover. Your data, your credentials and your pricing are confidential; so are our code and anything we mark as such. This does not cover what is already public, what a party already had, or what the law compels a party to disclose - and where the law compels us, we tell you first if we may. The obligation outlasts these terms.

Our total liability to you for everything arising out of the service in any twelve-month period is capped at the fees you paid us in the twelve months before the claim. Neither of us is liable to the other for lost profit, lost business, or indirect or consequential loss, however it arises.

The cap and the exclusion do not apply to death or personal injury caused by negligence, to fraud, to a breach of the confidentiality section, or to anything the law does not let us limit.

You cover us against third-party claims that arise from data you had no right to process, or from a breach of the terms your source or target platform sets - because those are the things only you can know.

We cover you against third-party claims that the application itself, used as these terms allow, infringes someone’s intellectual property. Each of us tells the other promptly about a claim and lets them run the defence.

We may change these terms, and the date at the top says when we last did. A change that reduces what you get or adds to what we ask is emailed to the owner of every organisation at least 30 days before it takes effect; a change that only clarifies takes effect when it is published. Carrying on using the service after a change means you accept it.

These terms are governed by the laws of India. Any dispute that we cannot settle between us is heard by the courts of Chennai, Tamil Nadu, India, and each of us agrees to that. Before either of us goes to court we will talk: raise it with us in writing and we will meet to try to resolve it within 30 days.

DataGrine, Chennai, India. For anything about these terms, an account, or a migration, email support@datagrine.com and a person will answer.