A complete, honest explanation of how MigrateStream moves your Salesforce Files to Google Drive. If you are evaluating this for an enterprise org, or want to know exactly what touches your data, this page is for you.
Steps 3 through 6 repeat for every file in your migration. Our server is not in this loop at all - it did its only job in the OAuth handshakes above, and is not contacted again for the rest of the run.
Both Salesforce and Google use the same shape of OAuth 2.0 Authorization Code flow with PKCE. For each one:
When a token expires, a matching small refresh script repeats just the token-renewal half of this exchange - still no storage, still nothing but a token in, a token out.
Browsers cannot keep an OAuth client secret confidential - anything shipped to the browser is visible to the user. Both Salesforce's and Google's Connected App / OAuth Client configurations require that secret for the code-for-token exchange, so that one step has to happen server-side. Everything else - listing files, downloading file content, uploading to Drive, tagging files - uses only the access token, which the browser already holds, and talks to Salesforce's and Google's APIs directly.
MigrateStream needs to know, on a second run, which files it already migrated, without ever storing that information on a server. It solves this entirely inside Google Drive itself:
One deliberate consequence of this design: if a file's content changes in Salesforce after it was already migrated, re-running the migration does not detect or re-pull that change. Matching is based on the file's identity, not a comparison of content - MigrateStream moves files once, correctly; it does not keep two systems continuously in sync.
A MigrateStream license key is a small, signed piece of data - not a login, and not an account. It is issued offline by Satrang, with no live connection involved at the time of issuance, and contains your customer name, which Salesforce org(s)/Google account(s) it covers, a data cap, and an expiry date.
Usage against your license's data cap follows the same zero-server-state principle as resume/duplicate detection above: it is measured from the migration records already sitting in your own Google Drive and your own browser, never from anything on our side, because there is nothing on our side to read it from - Satrang keeps no account for you and no ledger about you. What that measurement COVERS depends on the licence: those issued from August 2026 onward are scoped to their own sale and count only the files migrated under them, while earlier ones count everything ever migrated into that Google account, under any key. See the Set Up MigrateStream guide's license section for what that means in practice for your day-to-day usage display.
| Item | Stored on our servers? |
|---|---|
| Your Salesforce or Google password | Never seen at all |
| Your Salesforce or Google access/refresh token | No |
| File content (during download or upload) | No - passes through your browser's memory only |
| File names, sizes, or metadata | No |
| Your migration report (CSV) | No - built and downloaded entirely in your browser |
| Your license key or usage against its data cap | No - key lives in your browser's local storage only; usage is read from your own Google Drive, never reported to us |
| User accounts, usage analytics, tracking | None exist |
Our server runs a handful of small PHP scripts (the OAuth handshakes above, plus a config script). None of them write to a database, because there is no database. Standard web server access logs (IP address, timestamp, HTTP status) may exist as they do for any web server, but contain no token, query, or file data.
MigrateStream connects one Salesforce org and one Google account at a time. There is no multi-org tab system and nothing to isolate between sessions, since each browser tab already only ever holds one of each token, in memory, for its own lifetime.