Migrate from ResMan to Twenty CRM

ResMan Properties map to Twenty Companies because both represent organizations with a name, address, and industry. If the property portfolio has multi-unit buildings, we create a custom 'Property' object in Twenty keyed by the ResMan property ID and link Units to it. Property-level custom fields (InsurancePolicy, ZoningType, YearBuilt) migrate as custom fields on the Company or custom Property record.

Twenty has no standard Unit or RentalObject entity. We create a custom 'Unit' object with fields: UnitNumber (text), FloorPlan, SquareFootage, Bedrooms, Bathrooms, MarketRent, Status (Vacant/Occupied). The Unit links back to the parent Property via a relation field. Units without a parent Property default to the Property record's address. This requires creating the custom object schema in Twenty Settings → Data Model before the import sequence runs.

ResMan Tenants and Applicants both map to Twenty People. Contact details (name, email, phone) migrate directly. Applicant-stage records (pre-lease) land in Twenty People with a custom ApplicantStatus__c pick-list field ('Screening', 'Approved', 'Denied'). Tenants who have signed a lease link to the corresponding Opportunity via the opportunityId relation that we populate during the Opportunity import step.

ResMan Leases map to Twenty Opportunities — this is the core of the migration. LeaseStage ('Pending', 'Active', 'Month-to-Month', 'Ended') maps to Twenty Opportunity StageName values (we configure the pick-list in Twenty's Data Model before import). MonthlyRent maps to Opportunity Amount. LeaseStartDate and LeaseEndDate map to CloseDate (use end date as the close date for pipeline reporting) and a custom LeaseStartDate__c field. LeaseID is stored as Source_System_Lease_ID__c for delta-run de-duplication.

Twenty has no accounting ledger. Each lease's payment status (last paid date, balance due, late fees) migrates as custom fields on the Opportunity record: LastPaymentDate__c, BalanceDue__c, PaymentStatus__c. Payment history detail (each ACH transaction) is too granular for a CRM; we export it as a CSV rebuild reference and link a Note record with a summary table to the Opportunity for auditability.

ResMan maintenance tickets map to a custom 'WorkOrder' object with fields: Subject, Description, Priority (Low/Medium/High/Emergency), Status (Open/InProgress/Complete), Category, AssignedVendor, CreatedDate. Open work orders import as active records; closed ones import with Status='Complete' and CompletedDate__c. If the tenant contact exists in Twenty People, the WorkOrder links to it via a relation field. We do not migrate internal notes from the vendor communication thread — only the structured ticket fields and the final resolution note.

Twenty CSV import does not include file attachments. We export ResMan lease agreements, addenda, and tenant documents as a ZIP archive and generate a Note record per document with the original filename, document type, and a link to the archive. Re-upload of the actual files must be done manually in Twenty's Command Menu → Files, or via the GraphQL file upload endpoint. This is disclosed honestly — FlitStack does not promise automatic file migration.

ResMan owner and property manager users resolve by email match against Twenty workspace members. We invite the matched users before the migration so OwnerId fields on WorkOrders and Opportunities populate correctly. Unmatched owners are flagged in the pre-flight report and can be invited before the final run. Owner records without a corresponding Twenty account default to a fallback 'Unassigned' placeholder.

Prospect inquiries in ResMan (often captured via the website lead form) map to Twenty People with a custom Source__c field = 'ResMan Inquiry'. If the prospect was associated with a specific unit and had a scheduled tour recorded in ResMan, we create an Opportunity linked to the unit and the prospect with StageName = 'Tour Scheduled' so your Twenty pipeline reflects the prospect pipeline from the start.

ResMan inspection records (move-in, move-out, annual) have no direct Twenty equivalent. We create a custom 'Inspection' object with fields: InspectionType, ScheduledDate, CompletedDate, OverallCondition, UnitId (relation), TenantId (relation), and findings as a rich-text Note field. The inspection date timeline is preserved for compliance reporting. If the inspection triggered a work order, we link the Inspection record to the related WorkOrder via a relation field.