Migrate from Method:Field Services to Twenty CRM

Work Orders and Estimates have no native Twenty equivalent and require custom field scaffolding

Method Work Orders are a full field-service object with scheduling windows, technician assignment, customer signature capture, and location data. Twenty has no built-in work order or field service model — Opportunities are pipeline/deal records, not job tickets. FlitStack maps Work Order data into Twenty Opportunities with a set of custom fields (Scheduled Date, Technician, Priority, Work Location, Signature Collected). You will need to pre-create these custom fields in Twenty's data model (Settings → Data Model → Add Field) before the migration runs so the fields exist when the Opportunity records land. Estimates similarly require a custom estimate structure in Twenty. Without this preparation, the migration imports the data as bare Opportunities with no job-context fields, and your team loses the ability to see work order history by looking at a Twenty record.

Method's QuickBooks sync creates invoice and transaction records that cannot migrate to Twenty

Method's defining feature is its two-way QuickBooks Desktop and Online sync — invoices, sales receipts, payments, and accounting transactions all reconcile inside QuickBooks and sync back to Method. Twenty has no native accounting integration whatsoever. Any Method records that originated from QuickBooks sync (invoices, payment records, QuickBooks-generated transaction IDs) need to stay inside QuickBooks. FlitStack preserves these as a custom Billing Record object in Twenty with fields for invoice number, amount, status, and a QB reference link — this gives you a pointer back to the accounting system but does not rebuild the invoice inside Twenty. Your team will need to decide whether to keep Method running solely for QuickBooks reconciliation or rebuild the invoice view using a third-party integration between Twenty and QuickBooks.

Method API rate limits are tied to license count and require paginated extraction for large datasets

Method's API enforces daily limits calculated as 5,000 base plus 1,000 per active user per day. For an account with 10 dispatchers and 20 field crew technicians, that is a 25,000-request daily limit — but requests are consumed by every read and write operation, not just migration reads. Exporting work orders, estimates, custom table rows, and attachment metadata all count against this limit. FlitStack uses a paginated extraction strategy that spreads reads across the migration window to avoid hitting the limit mid-export. If your Method account has fewer active licenses than the API limit suggests due to inactive users, we run a pre-flight audit to confirm the actual rate limit before scheduling extraction. This prevents partial exports that leave the last-imported batch of records orphaned.

Twenty CSV imports require records to be sequenced in a specific dependency order

Twenty's import mechanism enforces referential integrity: a record cannot reference a related record that does not yet exist in the workspace. Specifically, Companies must be imported before People (because People.companyId links to Companies), and People and Companies must both exist before Opportunities can reference them. Method stores these relationships natively and does not enforce sequencing on export. FlitStack generates a sequenced migration plan: Companies first, then People, then Work Orders/Opportunities, then custom objects, then Tasks and Notes. Running imports out of this sequence produces orphaned records — contacts without a company, opportunities without a contact role. We validate the sequence before each import batch and flag any records that reference a parent not yet in Twenty.

Method custom tables require schema discovery before field mapping can be completed

Method allows administrators to create unlimited custom tables, each with its own set of fields and a custom screen. Unlike standard CRM objects (Contact, Company, Work Order), there is no universal reference for what custom tables a given Method account uses — a field-service company might have a custom table for Equipment, another for Site Visits, and a third for Parts Inventory, while a construction company might use different custom objects entirely. Before FlitStack can map these, we run a schema discovery pass using the Method API's FieldList endpoint to enumerate every active custom table and its fields. We then match field data types (string, number, date, pick-list, relation) to Twenty field types. Any Method relation fields that point to other custom tables require a dependency analysis to ensure the referenced table imports first.