What the evaluation covers
An evaluation runs in a sandbox organization: a separate DualEntry organization, seeded for your business, that you use to judge the product against your own numbers rather than against a demo dataset. Two things get decided at intake. The first is where the data comes from. A sandbox can be seeded with representative data built to a template, or imported from your own QuickBooks Online or Xero organization. Seeding from your own books is what turns a demo into a proof of concept, because the questions you actually have are about your chart of accounts, your entity structure, and your transaction volume. The second is the shape of the business being modeled. Intake captures your industry, the accounting systems you run today, your revenue types, your transaction volume band, and your entity tree, and selects an accounting template from recurring, services, inventory, asset-heavy, project, or generic. That structure is what makes the sandbox recognizable to your controller instead of generically plausible. Commercial terms for the evaluation, including whether a proof-of-concept migration is included, come from your account team.What the proof-of-concept migration includes
A sandbox seeded from QuickBooks Online or Xero uses the same migration machinery as a production cutover, not a separate import path. What lands is what would land later: your chart of accounts, classifications, customers and vendors, items, and your historical transactions as their own records rather than as summary balances. Scope is identical to a production migration, so migration data scope is the authoritative list of what moves, what you recreate, and what an ongoing connector supplies instead. Two entries on that page matter most during an evaluation, because they change what you can judge: Xero attachments migrate and QuickBooks attachments do not, and historical revenue recognition schedules are recreated rather than imported. The account mapping you do in the sandbox is the same mapping you would do in production, which is the part of the exercise with the longest tail. Doing it once against real accounts tells you how much cleanup your chart of accounts needs, and that answer is usually the most useful thing an evaluation produces.How your data is handled during an evaluation
The controls that apply to a production migration apply to an evaluation, because it is the same code path. Data handling during a migration covers them in full: OAuth authorization rather than shared passwords, source tokens encrypted at rest, a replication step into a schema DualEntry owns, and a disconnect that stops the pull and clears the stored credentials. Note that disconnecting revokes the grant at the source for Xero but not for QuickBooks, where you revoke it from your Intuit connected apps. Three things are specific to the sandbox and worth telling a security reviewer. A sandbox expires. Every sandbox organization carries an expiry date and is archived automatically when it passes. An evaluation copy of your books cannot quietly persist because someone forgot to clean it up, and the organization shows its own days-remaining count while it is live. Sandbox integrations point at demo endpoints. Where a sandbox uses supported integrations, they are routed to the provider’s demo or sandbox URLs rather than to your production accounts, so evaluating an integration does not touch the live system behind it. Access is scoped like any other organization. A sandbox is an organization in the same permission model as a production tenant, so role-based access governs who inside your company can open it, and DualEntry employee access follows the same reviewed, logged production access policy described in security and compliance. Send a security reviewer to the Trust Center for the SOC 2 Type II report, the subprocessor list, and the policies behind those controls.The evaluation timeline
The sandbox moves through a fixed sequence, and its current position is visible rather than inferred. The phases below are the ones the system itself tracks.
A seeded sandbox that fails to build surfaces as a failed request with its error rather than as a half-populated organization you would have to judge the product from.
What your team does
The customer time an implementation costs is not spread evenly. It concentrates in a small number of decisions that only your team can make, and the rest is DualEntry running a process while you wait. The table below is the full list of those decisions, so you can staff them and size them against your own team rather than against an average.
The mapping reviews are the largest line and the one worth staffing properly. Every other row is bounded by a checklist; mapping is bounded by how disordered the source chart of accounts is. The tie-out guide and the cutover runbook are the working documents for the rows below them, so a team that reads both in advance spends less time in the rows themselves.
Training and enablement
Training is scoped to what each person actually does rather than to the product surface. Someone entering bills needs the bill workflow and the approval routing behind it; a controller needs close, reporting, and period locking; an administrator needs roles, workflows, and integrations. Most of it is transferable from the source system, because the accounting has not changed. What genuinely differs is worth naming in advance: numeric account codes where QuickBooks and Xero used names, classifications in place of classes and tracking categories, and approval workflows as a configured control rather than a convention. Your first week with DualEntry is the self-serve path through the same material, and it works as pre-reading before a session or as the whole of training for a small team. Schedule training after tie-out rather than before it. A team trained on a sandbox that has since been remapped learns workflows against accounts that no longer exist, and the questions people actually ask are about their own posted transactions rather than about sample data.From evaluation to production
Work done in the evaluation is not thrown away when you sign. A sandbox that becomes your production organization is promoted rather than rebuilt: a fresh organization is provisioned, your users are moved onto it, and the previous one is archived. The mapping decisions and the structure you settled during evaluation carry into the organization you run. That path also changes how the production migration runs. The hands-off One-Click mode, which creates matching accounts and companies automatically, skips accounts with no transaction history, and advances into Data Sync without a manual gate, is available only to organizations that started from a migrated sandbox. That restriction is enforced by the platform rather than by policy: an organization that did not come through a sandbox is mapped by hand. The practical consequence is that an evaluation on your real data is also the setup work for the implementation. Teams that evaluate on a representative sandbox instead do the mapping once, later, under cutover pressure.Related reading
- Migration Data Scope: what migrates, what you recreate, what a connector brings
- How to Run a Migration Cutover: the implementation day, hour by hour
- How to Validate and Tie Out a Migration: the evidence a controller signs off on
- Data Handling During a Migration: credentials, retention, and security review
- Migration Failure Modes and Recovery: what recovers on its own and what you re-run
- Migrating from QuickBooks or Xero: choosing how much history to bring
- Your First Week with DualEntry: the self-serve training path