Migrating from QuickBooks Online to Kick: The Complete Accountant's Checklist

Kick markets itself as "self-driving bookkeeping software" and its own homepage features the testimonial "I was able to immediately replace QBO." The migration is real, and it works, and for a specific customer profile (US-based small businesses with straightforward operations on a modern fintech stack) Kick is a genuinely credible alternative to QuickBooks Online. But the migration is not what the marketing implies. It is currently in beta and available only to select firms. It has an accrual-ledger-first landmine that has no undo. It requires that bulk categorization work be complete in QBO before you start, because none of it carries over. It is one-way and static, with no reverse path. And the OAuth authorization flow contains a specific mistake that Kick's own documentation warns about three times.

This checklist walks through every phase of a QuickBooks Online to Kick migration from initial evaluation through post-migration validation, sourced to Kick's own documentation. Along the way I flag five specific gotchas that come out of QuickBooks and that most guides ignore: the beta-gate status that catches teams by surprise, the "Install for your firm" OAuth landmine, the account-numbers gap in the mapping step, the bulk-workflow loss on migrated transactions, and the QBO subscription cancellation that closes the API door before you can complete the pull. Each one deserves its own decision before cutover day.

Everything below is verified against Kick's documentation as of 15 September 2026. Kick ships fast, and specific parameters (beta gate, feature scope, integration coverage) may change. Verify anything critical directly with your Kick contact before executing.

The strategic framing worth naming upfront: Kick's mapping phase is "bounded entirely by how disordered the source chart of accounts is," and Kick's own guidance is to migrate only once bulk workflows in QBO are complete. A catch-up and cleanup engagement produces precisely the clean, rationalized, tied-out chart of accounts that makes a Kick migration fast. If your books need cleanup first, do the cleanup in QBO, then migrate cleanly.

💡 Key Takeaways

• The QuickBooks to Kick migration is currently in beta and available to select firms only. Confirm access before promising a client a migration

• The accrual ledger must be enabled BEFORE migration begins if you are migrating accrual data. Once a cash-basis migration completes, you cannot start a new migration; the only option is to remove the migration entirely and restart

• The "Install for your firm" landmine during OAuth authorization is Kick's most-repeated warning: select your firm first, then the specific client only

• Bulk categorization workflows do not carry over. Migrated transactions arrive as individual journal entries, so complete bulk workflows in QBO before migrating

• The migration is one-way and static. There is no reverse migration, no bidirectional sync, and no auto-refresh

• Migrate BEFORE cancelling the client's QBO subscription. A cancelled subscription closes the API door and there is no workaround

• Account numbers are not visible during mapping and must be updated on the Chart of Accounts tab after migration completes

• The migration is not time-boxed to Plaid's 6-24 month window. Kick pulls unlimited historical periods from QBO

• Verified 15 September 2026: Kick's migration is actively developed; verify current parameters before execution

Phase 0: The Decisions You Make Before You Start

Migration failure is almost always predetermined by decisions made or not made before cutover day. For a Kick migration, four decisions matter most.

Decision 1: Confirm beta access

Kick's documentation states this verbatim: "The QuickBooks migration feature is currently in beta and available to select firms. Reach out to your Kick contact if you don't see it in your workspace."

Before committing a client to a Kick migration timeline, confirm that your firm has access to the QuickBooks migration in your Kick workspace. This is the single fastest way to derail a migration project: promising a client a two-week timeline and then discovering the feature is not enabled for you.

Contact Kick sales or your Partner Success contact directly. If you are pursuing the AI-Native Program, migration access is one of the bundled benefits, but eligibility is not published and access is demo-gated. Get access confirmed in writing before your client-facing project timeline begins.

Decision 2: Cash basis or accrual basis migration

Kick documentation identifies this as the single most consequential pre-migration decision: "This must be done before migration begins; once a cash basis migration is complete, you can't start a new migration — the only option is to remove the existing migration entirely and restart."

The mechanics: if you plan to migrate accrual data, you must enable the accrual ledger in Kick before starting the migration. The path is Settings → Accounting → Accrual Ledger → Create Accrual Ledger. Do this before any migration action.

If you skip this step and run a cash-basis migration, there is no accrual retrofit. The only remediation is to remove the entire migration (deleting all imported data) and restart from Phase 1. This is not a workflow inconvenience. It is data loss followed by a full re-migration, and it will cost you the migration project's timeline.

The practical implication: decide cash vs accrual explicitly in a written scoping note with the client before touching Kick. If any doubt exists, default to enabling the accrual ledger first. You can migrate cash-basis data into an accrual-ledger workspace, but you cannot retrofit accrual capability into a cash-basis-migrated workspace.

Decision 3: How disordered is your source chart of accounts

Kick's own documentation names the strongest indicator of migration cost: "you can create new accounts, adjust types and subtypes, and leave accounts with no data unmapped — they won't bring anything over." The mapping phase is "a cleanup opportunity built into the process," meaning it will absorb every disorder in the source chart of accounts.

This determines migration cost more than any other factor. A cleaned-up, well-structured QBO chart of accounts maps in an afternoon. A disordered chart (parent accounts posted to, expenses miscategorized as COGS, revenue split across five accounts by accident, duplicate vendor accounts, orphaned accounts from prior bookkeepers) will consume days at the mapping phase and produce tie-out failures that force a full remove-and-restart.

The practical implication: clean up the QBO chart of accounts before the migration, not during it. Do the cleanup as a distinct engagement in QBO first, tie out the cleaned-up books, then migrate to Kick with a clean source. My messy chart of accounts analysis walks through what "cleaned up" means concretely and how much it changes migration timeline and cost.

Decision 4: When do you cut over

Three timing considerations matter for a Kick migration:

Bulk workflow completion in QBO. Kick's documentation is explicit: "Migrate when you're done with bulk workflows for the period." The reason: "Migrated transactions come over as individual journal entries — bulk categorization workflows on that historical data won't carry over." If you have bulk reclassification, bulk category changes, or bulk vendor updates queued in QBO, do them before migration. They cannot be replicated post-migration in Kick.

QBO subscription status. The warning that costs the most if missed: "Migrate before canceling the client's QBO subscription. Once the subscription is inactive, you won't be able to pull data from the API." Tell every client this in writing. A cancelled QuickBooks subscription is a closed door. If the client is planning to cancel their QBO subscription to save cost, coordinate the timing explicitly so migration completes and validates before cancellation.

Business event calendar. Do not migrate during active fundraising, tax season, quarterly close, board meeting preparation, or major business events. The migration deserves undivided attention from the migration owner, and business events divide that attention badly.

Phase 1: The Critical Pre-Cutover Settlements

Kick's documentation implies these; practical experience makes them explicit. Take these seriously; skipping any of them creates cutover-day failure.

Settlement 1: Beta access confirmed in writing

Do not begin the client-facing project until you have Kick's confirmation that migration is enabled in your firm workspace. This confirmation should include: your firm's Kick contact name and email, the specific workspace access confirmed, and any known limitations on your current beta access.

Settlement 2: Cash vs accrual decision documented

The decision should be made in writing with client sign-off before touching Kick. If accrual, the accrual ledger creation step (Settings → Accounting → Accrual Ledger → Create Accrual Ledger) becomes the first Kick action, before any migration configuration.

Settlement 3: QBO subscription-active status confirmed through cutover

Get written confirmation from the client that the QuickBooks Online subscription will remain active through migration completion and the 30-day validation window that follows. If the client plans to cancel post-migration, that is fine. What matters is that they do not cancel during migration.

Settlement 4: Bulk workflows completed in QBO

Any bulk categorization work, bulk reclassification, or bulk vendor updates that the client or their prior bookkeeper had queued should be executed in QBO before migration begins. Kick's documentation makes this explicit: those workflows do not survive migration. Confirm nothing is pending.

Settlement 5: The "Install for your firm" OAuth briefing

Kick's most-repeated warning across the documentation: "During QuickBooks Online authorization, do NOT click 'Install for your firm'. This is a common mistake. Select your firm first, then select the specific client only."

Brief every migration owner about this specific step before cutover day. The mistake is easy to make in the OAuth flow because "Install for your firm" appears prominently and reads like the right choice. It is not. Selecting the firm-level install locks the OAuth grant to the wrong scope and the migration will fail or produce wrong data. Correct approach: select your firm, then drill into the specific client only, then authorize.

Phase 2: The Five QuickBooks-Specific Gaps to Plan Around

Every migration guide covers the phases. Few cover the specific gaps that come out of QuickBooks that catch teams by surprise. Five of them deserve explicit planning for a Kick migration.

Gap 1: The beta gate that catches teams by surprise

Kick's QuickBooks migration remains in beta as of 15 September 2026. Even inside participating firms, workspace-level access can be inconsistent. Verify access in the specific workspace where migration will occur, not just at the firm level. This is the single most common project-derailer for teams new to Kick.

Gap 2: Account numbers aren't visible during mapping

Verbatim from Kick's documentation: "Account numbers aren't visible during mapping and will need to be updated on the Chart of Accounts tab after migration completes."

Practical implication: if your QBO chart of accounts uses account numbers (which most controller-managed charts do), those numbers will not appear in the mapping UI during Phase 4. You map accounts by name only. After migration completes, the account numbers need to be manually populated in Kick's Chart of Accounts tab. Plan a distinct post-migration task for this, and include it in the tie-out procedure.

Gap 3: Bulk categorization workflows do not carry over

Kick's documentation states this explicitly: "Migrated transactions come over as individual journal entries — bulk categorization workflows on that historical data won't carry over."

Practical implication: any bulk work you might want to do post-migration to correct historical categorization has to be done transaction-by-transaction in Kick. The migration outputs individual journal entries per historical transaction, not a bulk-updateable ledger. This is why Kick's guidance is to complete bulk workflows in QBO first. Kick documents that guidance precisely because attempting bulk work post-migration is materially harder than doing it in QBO before the migration.

Gap 4: The migration is static and does not auto-refresh

Verbatim from Kick's documentation: "Migration is static. It does not auto-refresh. If your QBO data changes after migration or you want to extend the date range, reach out to the Kick team to resync."

Practical implication: any changes made in QBO after migration completes do not flow to Kick automatically. If the client posts a late journal entry in QBO after migration completes, that entry does not appear in Kick. The workflow is: contact the Kick team, request a resync, wait for the resync to complete, re-validate. This is not a bug; it is documented behavior. But it changes how you handle any post-migration corrections in the source system.

Gap 5: The QBO subscription cancellation is a closed door

Verbatim: "Migrate before canceling the client's QBO subscription. Once the subscription is inactive, you won't be able to pull data from the API."

This is the highest-cost mistake in the entire migration workflow. A client who cancels QBO before migration completes has no recovery path. Kick cannot pull the data. There is no workaround. The client must reactivate the QBO subscription (potentially at a new higher tier if their old tier is no longer available), migrate cleanly, then cancel again.

Practical implication: put this warning in writing to every client who is planning to cancel QBO. Include the specific cutover completion date after which cancellation is safe. Do not assume the client remembers a verbal warning.

Phase 3: The Eight-Phase Runbook (Kick's Own Framework)

Kick's documentation organizes the migration into eight phases. Follow the sequence rather than improvising during execution.

Phase 3.1: Pre-Migration

If migrating accrual data, enable the accrual ledger first: Settings → Accounting → Accrual Ledger → Create Accrual Ledger. This step must complete before any migration action. Cash-basis migrations do not require this step.

For all migrations: verify beta access is enabled in the workspace where migration will occur. Confirm the firm-level access covers the specific client workspace.

Phase 3.2: Scope the Migration

Confirm how far the books are closed in QuickBooks. Kick documentation: "You don't need to be completely finished in QBO before migrating. Migrate when you're done with bulk workflows for the period."

To check how far back the source data extends: open the P&L in QuickBooks and toggle Display columns by Year with All Dates. The earliest year with data is your historical boundary.

Agree the migration start date in writing. Kick's documentation: "Everything before this date comes from QBO; Kick takes over from that date forward." The Kick bookkeeping start date is automatically set to the day after your migration end date. Coordinate this timing with any pending QBO work; you cannot post to QBO after the migration end date without triggering a resync.

Phase 3.3: Start the Migration

For a new Kick client: Clients → Add client → "How would you like to set up your Chart of Accounts?" → QuickBooks Online.

For an existing Kick client: workspace Settings → Accounting → Accounting migration → New migration.

The OAuth landmine: "During QuickBooks Online authorization, do NOT click 'Install for your firm'. This is a common mistake. Select your firm first, then select the specific client only."

The connection is read-only and one-way. Kick pulls data from QBO but does not push anything back. This is not a two-way sync and does not become one after migration completes.

Phase 3.4: Map the Chart of Accounts

Kick auto-generates tasks after migration completes. Open the Map Accounts task. QuickBooks accounts appear on the left, Kick accounts on the right. Bank and credit card accounts show "task created" — skip them here, they get connected in Phase 6. For custom accounts, hover the row and click Create Account.

The mapping decision that deserves extra care: Kick documentation calls this out specifically: "Pay extra attention to equity accounts." Multi-owner entities often need custom mapping, such as splitting contributions from distributions per owner. Standard equity mapping in Kick may not match the multi-owner structure that a QBO chart carries. Plan the equity mapping explicitly before starting the mapping task.

The cleanup opportunity: Kick's documentation states this explicitly. During mapping you can create new accounts, adjust types and subtypes, and leave accounts with no data unmapped. Accounts left unmapped do not bring anything over. A migration is the cleanest moment to rationalize a bloated chart of accounts, and Kick's mapping step is where you do it.

Phase 3.5: Verify

Accounting → Profit and Loss → confirm the P&L ties to QuickBooks for the migrated period.

Kick's useful detail: "beginning balances for reconciliation are auto calculated, so no manual entry is needed." Verify the auto-calculated beginning balances against QBO's balance sheet as of the migration start date. Document any material discrepancies before proceeding to Phase 6.

Phase 3.6: Connect Live Accounts

Individual Connect Account tasks are auto generated per bank and credit card identified during migration. Connect via Plaid or use the Universal Importer for unsupported banks.

Plan for Plaid's known history depth constraint: "typically 6 to 24 months depending on the institution." Some banks provide only 3 to 6 months. If historical bank data older than the Plaid window is needed, use the Universal Importer with CSV exports from QBO or directly from bank statements.

Phase 3.7: Map Migrated Accounts to Live Feeds

Tasks → Map migrated data. For each migrated bank or card account, map to the matching live integration account. Kick's documentation: "this creates one continuous transaction feed."

For accounts that are no longer active, Mark as closed. This preserves the historical migrated data while preventing Kick from attempting to sync a live feed that no longer exists.

Phase 3.8: Things to Know Post-Migration

Migration is static. Kick's own words: "It does not auto-refresh. If your QBO data changes after migration or you want to extend the date range, reach out to the Kick team to resync."

To redo a migration: Settings → Accounting → Accounting migration → remove and restart. Kick's documentation: "This deletes the migration so you can start completely fresh." Understand that "deletes the migration" means deleting all imported data. This is not a partial fix mechanism.

Phase 4: The Validation Approach

Tie-out procedure with workpaper-grade discipline. The morning after the migration completes, execute this validation before proceeding to Phase 6 (Connect Live Accounts).

Test 1: P&L Tie-Out for the Migrated Period

Compare the QBO Profit and Loss statement for the migrated period against Kick's Profit and Loss for the same period. Standard procedure:

• Pull QBO P&L for the full migrated date range

• Pull Kick P&L for the same range

• Compare total revenue by month

• Compare total expenses by month

• Compare net income by month

Differences at this stage typically trace to unmapped accounts (accounts left off the mapping worksheet) or equity account mapping problems. Fix mapping errors before proceeding.

Test 2: Balance Sheet Review for Stale Items

Kick's Close Guide includes practical multi-year advice worth applying here: "filter the report for the full date range (e.g., 1/1/2023 - 12/31/2025) and view columns By year to see annual data side-by-side."

Apply this to the Kick Balance Sheet after migration. Look for:

• Stale AR from customers no longer active

• Stale AP from vendors no longer active

• Clearing accounts that carry balances (should be zero)

• Suspense accounts holding unattributed amounts

• Beginning balance discrepancies vs prior-year QBO balance sheet

Every stale item requires an explicit decision: correct it, document it, or leave it and note it in the tie-out documentation.

Test 3: Retained Earnings Roll-Forward

Verify retained earnings ties from the beginning of the migration period through the migration end date:

• Beginning retained earnings (from prior period QBO closing balance)

• Plus net income for each period migrated (from QBO income statement)

• Less distributions or dividends (from QBO owner draws)

• Equals ending retained earnings (should match Kick balance at migration end date)

Differences in retained earnings usually trace to either mapping errors on income or expense accounts, or distributions categorized differently in source versus destination. For multi-owner entities where equity mapping required special attention in Phase 4, expect this test to require careful investigation.

Test 4: Account Numbers Verification

Since Kick's mapping step does not display account numbers, verify that the account numbers populated in Kick's Chart of Accounts tab match the QBO chart of accounts. This is a distinct post-migration task and deserves explicit documentation. Missing or incorrect account numbers will not affect the P&L or balance sheet tie-out, but they will affect financial statement customization, external report generation, and any downstream integration that relies on account codes.

Common Pitfalls, from Kick's Own Documentation

Kick's documentation provides a common gotchas table verbatim. Watch for each explicitly.

1. Clicked "Install for your firm" by Mistake

Resolution: Back out and re-select firm, then the client only. If the migration has already started with the wrong scope, remove the migration entirely (Settings → Accounting → Accounting migration → remove and restart) and begin again.

2. Books Aren't Substantially Closed in QBO

Resolution: Hold off on migration. Kick's documentation: "Minor cleanup is fine post-migration, but bulk workflows are lost." Complete bulk work in QBO first.

3. QBO Data Was Updated After Migration

Resolution: Migration is static; contact the Kick team to resync. Do not attempt to manually reconcile post-migration QBO changes without a resync; you will produce inconsistent data.

4. Account Mapping Went Wrong

Resolution: Remove and restart the migration, then redo from Phase 3. This is not a partial fix. All migrated data is deleted and re-pulled from QBO. This is why predetermined mapping in Phase 4 matters.

5. Bank Account Is No Longer Active

Resolution: Mark as closed in the Tasks mapping step. This preserves historical data without attempting to sync a nonexistent feed.

6. Institution Not Supported by Plaid

Resolution: Use the Universal Importer. Plaid supports over 10,000 institutions, but coverage gaps exist. The Universal Importer accepts CSV imports for any bank; plan for extra manual work if this applies to your client's institutions.

What Migrates and What Does Not

Migrates

• Chart of accounts with mappings you configure in Phase 4

• General ledger transaction history for unlimited historical periods (not time-boxed to Plaid's 6-24 month window)

• Counterparties (customers and vendors, optional)

• Auto-calculated reconciliation beginning balances

• Bank and credit card account identification (for later live-feed connection)

• If selected: class and location tags with nesting preserved

Does Not Migrate, or Migrates Degraded

• Account numbers. Not visible during mapping; must be updated on Chart of Accounts tab post-migration.

• Bulk categorization workflows. Everything arrives as individual journal entries.

• Accounts left unmapped. They do not bring anything over.

• Live bank feeds. Connected separately in Phase 6 and linked in Phase 7.

• Any subsequent QuickBooks changes. The migration is a one-time static pull. Contact the Kick team to resync if source data changes materially.

Non-QBO Sources

Kick's documentation confirms chart of accounts setup can be sourced from QuickBooks Online, Intuit Enterprise Suite, Xero, Digits, Puzzle, and Bench. But only QuickBooks has a live API migration path. All other sources use a manual GL-based migration with exported files, initiated through your Kick representative. If you are migrating from Xero, Digits, Puzzle, or Bench, plan for materially more manual work than a QBO migration requires.

The Reversibility Reality

Kick's documentation is direct: "Migration is static." There is no two-way sync. There is no reverse migration. There is no rollback other than removing the migration entirely.

A client who moves to Kick and later decides to return to QuickBooks Online has to rebuild in QBO from Kick data exports. This is a real business decision worth naming plainly to the client before you recommend the move.

This is not unique to Kick. Every AI-native accounting platform launched in the last three years has similar structural characteristics. Puzzle, T:0, DualEntry, Rillet, and Campfire all treat migration as forward-only. What matters is that you and the client understand this together before executing, and document the decision in the engagement scope. My T:0 vs Puzzle comparison covers the broader migration reversibility landscape across AI-native platforms.

Saying this plainly to a client wins trust. Pretending the migration is easily reversible loses it when the client later discovers the reality.

The Bottom Line

Migrating from QuickBooks Online to Kick is executable in a compressed timeline when the beta access is confirmed, the cash-vs-accrual decision is made before touching Kick, the QBO chart of accounts is cleaned up first, the OAuth authorization avoids the "Install for your firm" landmine, and the eight-phase runbook is executed with workpaper-grade discipline.

The migration succeeds when someone with CPA-level judgment owns the mapping decisions and validation procedure. It fails when the process is treated more casually than it deserves. Kick's migration engine is genuinely thoughtful for a beta feature, and the auto-calculated beginning balances plus unlimited historical periods make it materially easier than a Xero, Digits, or Puzzle migration into Kick (which are all manual GL-based). But "better than the alternatives" does not mean "one-click."

The specific gotchas that catch most migrations by surprise (the beta gate, the accrual-ledger-first landmine, the "Install for your firm" OAuth mistake, the account-numbers-not-visible mapping gap, the bulk-workflow loss on individual journal entries, the QBO subscription cancellation closing the API door, the static migration that does not auto-refresh) are all documented in Kick's own materials. Reading the documentation carefully before starting eliminates most of them.

For catch-up cleanup engagements specifically, the migration is materially easier when the QuickBooks Online source is already cleaned up. A disordered source chart of accounts absorbs every hour of the mapping phase, per Kick's own guidance. Cleaning up first, then migrating cleanly, produces better outcomes than trying to clean up during the migration itself.

Kick ships fast, and specific parameters (beta access scope, feature coverage, integration completeness) may evolve. Verify current documentation before executing any migration and treat this checklist as a workpaper template that needs updating rather than a permanent artifact.

Ready to migrate from QuickBooks Online to Kick?

Most CPAs advising on this migration have not actually done it. Kick's documentation is publicly available, but reading it carefully takes time and translating it into execution requires the specific accounting judgment that most bookkeepers do not have. This creates a real gap between what marketing content claims and what execution actually requires.

Catch Up Clean Up specializes in the specific engagement pattern that most Kick migrations follow. Historical cleanup of the QBO source, chart of accounts rationalization at the mapping phase, coordination with Kick's Partner Success team on beta access, workpaper-grade tie-out procedure, and post-migration reconciliation of the account numbers gap. Because I am a Certified Puzzle Advisor at Preferred Partner tier and platform-agnostic in my advisory approach, I can honestly evaluate whether Kick is the right destination for your business or whether Puzzle, Xero, or continued QuickBooks Online is a better fit.

The strategic reality worth naming: Kick has no Shopify, no Amazon, no e-commerce integration of any kind, no inventory, no sales tax engine, and no multi-currency support. If your business runs any of these workflows at material scale, Kick is not the right ledger today. For US-based service businesses with straightforward operations, Kick's Personal-entity handling, native multi-entity, and AI-native categorization are genuinely differentiated. Which one fits depends on your specific business.

What you get:

• A 30-minute diagnostic call to assess Kick fit for your specific business

• Objective evaluation across Kick, Puzzle, QuickBooks Online, Xero, and other AI-native platforms

• Historical QBO cleanup before migration to materially reduce migration cost and complexity

• Coordination with Kick's Partner Success team on beta access confirmation

• Chart of accounts rationalization at the mapping phase

• The eight-phase migration runbook executed with workpaper-grade discipline

• Post-migration account number population and validation

• Multi-year tie-out procedure with documented reconciling items

• Post-migration integration setup (Plaid, Universal Importer, Ramp, Mercury, Gusto, Stripe)

• Ongoing Kick bookkeeping if Kick is the right destination

• Platform-agnostic advisory so the recommendation is based on your business, not our certifications

Book a free consultation and we will diagnose your migration situation honestly.

Frequently Asked Questions

How long does a QuickBooks Online to Kick migration take?

For a straightforward migration with cleaned-up source chart of accounts, cutover executes in a single afternoon. Chart of accounts mapping and validation adds one to two business days. For migrations with disordered source charts of accounts, timeline extends significantly as mapping decisions become harder and validation reveals more reconciling items. Beta-gate confirmation and Partner Success coordination can add days to weeks at the front of the project.

How much does the Kick migration cost?

Kick charges nothing for the migration itself. Software costs are Kick's normal subscription pricing (Basic at $40/mo or Plus at $100/mo). Professional services for migration execution typically range $2,500-$8,000 depending on complexity, source data cleanliness, and how much validation the internal team executes. Adding pre-migration QBO cleanup ranges $3,000-$12,000 depending on the extent of cleanup required.

Do I need to keep my QuickBooks Online subscription after migration?

Only through the validation window (typically 30 days post-migration). Once you have confirmed the tie-out and captured any historical reports needed, QBO can be cancelled. But you must not cancel before migration completes, because Kick's documentation is explicit: a cancelled QBO subscription closes the API door and there is no recovery path.

Should I run QBO and Kick in parallel for a month?

Kick does not publish specific parallel-running guidance. Practical experience: for a clean migration with strong validation, parallel running adds cost without adding much value. For a migration where source data quality is uncertain or where the client is anxious about the transition, one month of parallel running provides psychological comfort but doubles the data entry work. Discuss with the client and decide based on their specific risk tolerance.

Can I reverse a Kick migration if it goes wrong?

No. Kick's documentation states migration is static and one-way. There is no reverse migration, no bidirectional sync, and no rollback other than removing the migration entirely from Kick (which deletes all imported data). A client who moves to Kick and later returns to QBO must rebuild from Kick data exports. This is worth naming plainly before recommending the move.

Do QuickBooks attachments migrate to Kick?

Kick's documentation does not explicitly address attachment migration for QBO imports. The Kick migration is API-based and covers chart of accounts, general ledger data, and counterparties. Any historical attachments in QBO should be treated as staying in QBO unless explicitly confirmed otherwise with the Kick team.

What is the "Install for your firm" landmine?

Kick's most-repeated warning: during OAuth authorization, do NOT click "Install for your firm." This is a common mistake because the button reads like the right choice. It is not. The correct sequence: select your firm, then drill into the specific client, then authorize. Selecting the firm-level install locks the OAuth grant to the wrong scope and the migration will fail or produce incorrect data.