Security

SuiteMigration moves accounting data — your ledger, your customers, your transaction history — between systems you control. We know that asking to connect to your accounting system and your NetSuite account is asking for a lot of trust. This page describes how the Software is built and operated, and the choices we have made to protect your data.

This page is provided for information. It describes how our systems are designed as of the date above, is not a warranty or a contractual commitment, and may change as our infrastructure and practices develop. Our binding commitments are in our Terms of Service, Data Processing Agreement, and Privacy Policy, which control in the event of any inconsistency with this page.

1. Our Approach

Four ideas shape how we think about security, and they run through everything below.

We use your data only to provide the Software. That includes running your migration or Migration Readiness Audit and providing related security and support. We do not mine, sell, rent, license, or use Customer Data to train AI models — ours or anyone else’s. These are contractual commitments in Sections 7.1 and 7.3 of our Terms of Service, not policies we could quietly change.

We don’t delete your data on a timetable of our own. Your migration data stays available while you have access to it — some customers want to reference it long after go-live, and we would rather not destroy something you were relying on. You can delete it yourself in the Software whenever you want. Section 16 has the full picture, including when access to a paid Migration can end.

We retrieve your data comprehensively, because the first thing we do is measure it. Before anyone decides whether to migrate — or how much to migrate — the Migration Readiness Audit examines your source data as a whole to find what would break an import. It cannot assess what it has not read. So the Software retrieves everything your source system exposes to us — including records you may ultimately choose to leave behind.

We build on AWS and separate our environments. AWS provides independently audited physical infrastructure and managed security services. We operate local, development, and production in separate AWS accounts and centrally manage human access through AWS IAM Identity Center. We remain responsible for configuring those services, controlling access, and protecting how Customer Data flows through the Software. Section 3 is explicit about which parts of our posture are inherited and which are ours.

2. What We Process

If your source system exposes it, assume we retrieve it. The Software does not take a selected subset of your accounting data. It retrieves everything the source system’s API makes available to us — and the following are examples rather than a list: master data, transactions, employee records, tax rates and tax payments, cash expenses, reports such as the trial balance and profit and loss, and the metadata that describes how your books are put together, including terms, payment methods, departments, categories, and custom fields.

We also hold the mappings you define, the reconciliation output, the records written to your destination system (for example NetSuite), and the account information of the users you authorize.

Two of those are worth explaining. We retrieve employee records because transactions carry the identity of whoever created them, and reproducing that attribution in your destination system means knowing who those people are. We retrieve reports — the trial balance, profit and loss, and similar — because reports are what reconciliation compares against: showing that a migration landed correctly means checking against the figures your source system itself reports, not only the records underneath them.

Connecting a source system begins that retrieval, and it is not a configurable subset. The Software pulls the full dataset first, and everything after it — assessing the data, mapping it, migrating all or part of it — works from what was retrieved.

Why we retrieve everything. Source accounting systems can’t answer the questions a migration assessment has to answer. Depending on the system, they may not report how many transactions exist, how many line items sit inside them, which payments are undeposited, or where records duplicate one another. The only way to measure those things is to retrieve the data, store it, and measure it directly. That same completeness is what makes reconciliation possible later, because proving a migration is complete means comparing against the whole source, not the portion you selected.

So we retrieve transaction history in full even where you go on to migrate only some of it. Scope decisions also shift during a project, and we would rather not return to your source system each time they do.

Your source and destination systems are yours, connected at your direction. They are not our sub-processors, and your use of them is governed by your own agreements with those providers. We describe this in our Data Processing Agreement.

3. Hosting and Infrastructure

The Software runs on Amazon Web Services in a single region in the United States (US East, Northern Virginia). Your data is stored in the US by default. UK and EU data residency is available for enterprise customers on request.

Our local, development, and production environments operate in separate AWS accounts, and Customer Data is stored only in the production account. The local account supports development on our own machines and holds only the secrets that work needs; it runs no application infrastructure or database. Human access to AWS is centrally managed through AWS IAM Identity Center using individual identities protected by multi-factor authentication. Permission assignments restrict personnel to the AWS accounts and roles required for their work.

The application runs on AWS Elastic Beanstalk across separate web and background-worker environments. Customer Data is held in a managed Aurora PostgreSQL database, with a managed Redis cache holding transient job state. Both sit in private subnets spanning two availability zones and are not reachable from the public internet: the database has no public endpoint, and network rules permit connections only from the application’s own compute — never from an IP address range. Only the load balancer is publicly exposed.

Requests to our API pass through AWS WAF before reaching the application. It blocks traffic originating from certain countries, filters requests from IP addresses on AWS’s managed reputation and DDoS lists, and rejects requests probing for common credential and configuration paths. WAF request logs are written with authorization headers, cookies, API keys, CSRF tokens, and query strings redacted, so credentials do not appear in them. Amazon GuardDuty provides continuous threat detection on the account holding Customer Data, and AWS Config continuously records the configuration of our AWS resources.

Running on AWS means a substantial part of our security posture is provided and independently audited by AWS rather than asserted by us. AWS is responsible for the security of the cloud — data-center physical and environmental controls, hardware and media lifecycle including secure decommissioning, host and hypervisor isolation between tenants, and the physical network. AWS maintains its own SOC 1, SOC 2, ISO 27001, and PCI DSS attestations covering that infrastructure, and publishes them through AWS Artifact.

We are responsible for security in the cloud — how we configure those services, how the application is built, who on our team can reach what, and how your data flows through it. The rest of this page is about our half of that line.

AWS’s certifications cover AWS’s infrastructure. They are not certifications of SuiteMigration, and we do not present them as such. Our own compliance posture is described in Section 15.

4. Tenant Separation

Your workspace is the boundary between your data and everyone else’s. Your projects, migrations, connections, and every record we pull from your accounting system belong to your workspace.

That workspace comes from your session, not from anything in the request. Once you’re logged in, the system already knows which workspace you’re acting as, so there’s nothing in a request that could point it at a different one. Switching workspaces requires an active membership in the one you’re switching to, checked against the database at that moment.

When a request names a project, migration, or connection, the Software checks it against your workspace before returning anything, so a request can’t reach into a project or migration outside it.

If you ask for a record that exists but isn’t yours, we tell you it wasn’t found rather than that you’re forbidden from seeing it. A “forbidden” response would confirm that the record exists, revealing its existence to someone outside your workspace.

5. Encryption

Data is encrypted in transit between you, the Software, and the systems you connect, using TLS. Data at rest in our AWS environment is encrypted using AWS-managed encryption on the underlying storage services, with keys managed through AWS Key Management Service.

6. Credentials for the Systems You Connect

This is the part that matters most, so it gets its own section.

To run a migration, the Software needs access to your source system and your NetSuite account. Five principles govern how we handle that access:

We hold as little as possible. Where a provider supports OAuth, we hold a scoped, revocable token rather than a username and password. We connect to QuickBooks Online and Xero over OAuth 2.0. For NetSuite we use both OAuth 2.0 and token-based authentication: OAuth 2.0 for its REST web services, and token-based authentication for its SOAP web services. From Xero we request read-only access: our permissions there cover reading transactions, contacts, and settings, and nothing else. For QuickBooks Desktop and Enterprise we do not hold your accounting credentials at all; that connection is brokered by Conductor, listed on our Sub-processors page. Because a migration runs over days rather than minutes, we also hold the refresh token that keeps a connection alive. It sits under the same encryption as everything else here, and is erased with the Connection when you delete it.

You can revoke us, and you can delete what we hold. Access is granted from your side and can be withdrawn from your side, in your source system and in NetSuite, without depending on us to act. Connections are held at the Project level, since the Migrations in a Project usually target the same destination — and you can delete a Connection from the Software at any time.

We encrypt them separately from everything else. Connection credentials are encrypted by the application before they are written to the database, using authenticated encryption, and the key material is held in AWS Secrets Manager rather than alongside the data. Storage-level encryption protects the database; this protects the credentials a second time, independently of it. A database backup or snapshot contains only ciphertext for these fields. The same treatment covers the secrets behind multi-factor authentication.

Our people do not see your credentials. Connection credentials are excluded from the administrative interface our team uses, so they are never decrypted for display. A SuiteMigration employee looking at your Connection sees which system it points at and which company it belongs to, not the token behind it.

Deleting a Connection erases what we hold. When you delete a Connection, it is withdrawn from use straight away, and the stored credentials are then erased from our database. We delete the record itself; we don’t leave it flagged as deleted and sitting in place. Deleting a Connection removes our copy of the credentials but does not revoke the access you granted at the provider; to do that, disconnect SuiteMigration from within your source system or NetSuite.

7. Application Access and Authentication

8. Secure Development

9. Logging and Monitoring

We use application logs and error and performance monitoring to detect faults, support production operations, and investigate security events. We do not maintain a record-level log of Customer Data viewed through Django Admin.

10. Internal Access to Customer Data

Access to production systems and Customer Data is limited to personnel with a business need. Our team is small, which means access is granted deliberately rather than by default, and removed when someone’s role changes or they leave.

Our developers can see your records, and here is why. Migrations fail on the specifics of real data — a malformed record, an unexpected field value, a transaction that behaves differently from the thousand before it. Diagnosing that means looking at the actual records. Most of our developers therefore have access to the Software’s administrative interface in production, which they use for maintenance, support, and troubleshooting, and which can expose Customer Data. It is used for that purpose and no other.

That access runs through the application rather than around it: records changed through the administrative interface remain subject to the Software’s own validation and controls, which would not apply to changes made directly against the database.

Access to our AWS infrastructure is a separate path from access to the Software. AWS access is centrally assigned and managed through AWS IAM Identity Center; access to the administrative interface is controlled within the Software itself.

11. Corporate and Endpoint Security

Our internal systems run on Google Workspace, configured so that multi-factor authentication is required on all staff accounts.

12. People

13. Sub-processors and Vendors

We publish a complete, current list of every third party that processes Customer Data on our Sub-processors page, including what each one does and what data it sees. That page is the source of truth and is referenced by our Data Processing Agreement.

We keep this list short on purpose. Card numbers are handled by Stripe and never stored by us. Our sub-processors are engaged under written terms requiring data-protection obligations materially consistent with our DPA.

14. AI and Your Data

We do not use your data to train AI models, and we do not let anyone else use it for that either. This is a contractual commitment in Section 7.3 of our Terms of Service, not just a policy statement.

The Software includes one optional, clearly-marked, click-to-use feature that suggests field mappings using AI. It runs only when you choose to use it for a specific mapping task. Requests are processed through AWS-managed Amazon Bedrock inside our own AWS environment — not sent to a separate third-party AI vendor. Per AWS’s published Bedrock documentation, AWS states that Bedrock does not store inputs or outputs, does not share them with the model providers whose models it hosts, and does not use them for training.

We also do not sell, rent, license, or mine your data. Providing the Software to you is the only thing we use it for.

15. Compliance and Certifications

We want to be straightforward about where we are rather than imply more than we have.

Today, we can provide: our Data Processing Agreement, including GDPR-oriented terms and our technical and organizational measures; our published sub-processor list; and direct answers to specific questions about our architecture and controls.

Our infrastructure provider is independently audited. As described in Section 3, AWS maintains SOC 1, SOC 2, ISO 27001, and PCI DSS attestations covering the infrastructure we run on. Those are AWS’s certifications, not ours.

We do not currently hold a SOC 2 or ISO 27001 certification of our own. We would rather say that plainly than describe ourselves as “aligned with” a standard we have not been audited against.

We are working toward SOC 2 Type II. We use a compliance-automation platform to document our policies and monitor our controls, and we are working through that process now. We have not completed an independent audit, and we will say so here until we have.

16. Data Retention and Deletion

Your data stays available while you have access to it. We do not delete your migration data on a schedule of our own — you may want to reference it, compare against it, or run a further migration from it.

You can delete a Migration through the Software whenever you want. We may also discontinue access to a Migration that is subject to Fees, as permitted by Section 2.6 of our Terms of Service and on the notice required there. When a Migration is deleted, or when its access is discontinued, we delete the Customer Data associated with it, as described in Section 7.6.

Separately, on termination or expiration of your Order Form, we delete or return Personal Data under Section 11 of our Data Processing Agreement.

In each case, deleted data may persist for a limited period in backups, logs, or similar records, and where retention is required by applicable law, before being fully purged.

17. Incident Response

If we confirm a security incident affecting your data, we will notify you without undue delay and take reasonable steps to mitigate it. Our specific obligations are set out in Section 7.2 of our Terms of Service and Section 10 of our Data Processing Agreement.

18. Availability and Continuity

19. Reporting a Vulnerability

If you believe you have found a security vulnerability in the Software, please tell us at security@suitemigration.com. We will acknowledge your report and work to understand and address the issue, and we will not pursue action against researchers who report in good faith, avoid privacy violations and service degradation, and give us reasonable time to respond before disclosing publicly.

20. Talking to Us About Security

If your team has questions about how we handle your data, we would rather have the conversation than hand you a document. Reach us at support@suitemigration.com and we will get you what you need — our DPA, our sub-processor list, and straight answers about our architecture and controls.

21. Changes to This Page

We will update this page as our systems and practices develop. It describes our design as of the date at the top and may change without notice. It is not part of any agreement between us.

---

Questions: support@suitemigration.com. Related: Terms of Service · Data Processing Agreement · Privacy Policy · Sub-processors.