Migrate from farmerswife to Asana

farmerswife Projects map directly to Asana Projects, preserving Project name, status, start and end dates, client link, and description. Custom fields on Projects migrate to Asana custom fields. Budget fields from farmerswife (total budget, cost-to-completion) migrate to Asana custom numeric fields on the Project; Asana Business project budget totals are set at the project level. The Project creation date and last-modified date migrate as custom fields because Asana does not expose a created-at date on the Project itself via the standard UI.

farmerswife Activities are scheduled work items with their own date ranges, duration, and attached Bookings. Each Activity maps to a top-level Asana Task within the mapped Project. The Activity's start date, end date, and notes migrate to Task start date, due date, and description. If an Activity contains more than 100 Bookings, we split it into a parent Task and subtasks to keep Asana's assignee model manageable. Activity status (scheduled, in-progress, completed) maps to Asana task completion.

Each resource Booking within a farmerswife Activity (linking a Resource or Object to an Activity at specific times) maps to an Asana Subtask on the parent Activity Task. The Subtask title includes the resource name, booking type, and time slot. Custom fields on the Subtask carry resource classification (Crew, Equipment, Studio), and the original Booking duration migrates as a custom numeric field. Booking conflicts flagged in farmerswife are catalogued as a note on the Subtask for the customer to resolve post-migration.

farmerswife Objects cover distinct entity types: People contacts, physical resources, rooms, and services. People map to Asana workspace Members (User records) and are assigned to Tasks via the assignee field. Physical Resources and Rooms are catalogued as Tags (Crew, Equipment, Studio) attached to the relevant Tasks, with additional metadata stored in custom fields because Asana does not have a native resource entity. Services are stored as tags with rate information in custom numeric fields. Object Types (e.g. 'Edit Suite', 'Camera Package') map to Tags and multi-select custom fields.

farmerswife Clients are distinct entities linked to Projects and Rate Cards. We map them to Asana Organizations (for multi-project clients) or Companies within a Portfolio. Client contact details migrate as Organization fields; the Client Rate Card link is preserved as a custom text field referencing the client's rate structure for the customer's admin to configure post-migration.

farmerswife Budgets contain line items with individual Price Agreements (fixed-price per item), budget totals, and cost-to-completion tracking. Asana has no line-item budget object. We flatten Budgets by summing all line-item totals into a single project-level budget custom field. Any line items where individual Price Agreement terms differed from the project-level rate are flagged in a separate custom field for the customer's review during UAT. Full budget detail (per line item, per Price Agreement) is delivered as a CSV export alongside the migration for manual reference.

farmerswife Rate Cards are scoped to Clients or Projects and define day rates, overtime rates, and custom pricing tiers. Asana has no rate card object. We export the full Rate Card structure and map rate values to custom numeric fields on Tasks, tagged by rate type (day rate, overtime, weekend). The admin selects whether to apply client-specific rates or project-level rates during scoping; the chosen strategy is applied as a transform rule during migration. Rate visibility permissions from farmerswife's multi-layer permission model are noted but cannot be enforced in Asana without manual role configuration.

farmerswife Users have Project Rates Permissions and Client Rates Permissions layered independently, with an 'Always Allow' list controlling who can modify rates outside their own projects. Asana uses a three-tier role model (Admin, Member, Guest) scoped to the workspace or team. We map farmerswife Admins to Asana Admin, active producers and coordinators to Asana Member, and read-only clients or external crew to Asana Guest. The granular rate visibility hierarchy does not map directly and requires the customer's admin to configure equivalent permissions manually post-migration; we document the original permission matrix for reference.

farmerswife Time Entries are logged against Activities and Bookings and feed into invoicing. We map them to Asana Tasks linked to the relevant Project and Activity Task. Time entry duration migrates to a custom numeric field (hours), and the time entry date becomes the Task start date. Asana's native time tracking (on Business tier) can be enabled post-migration for manual time logging; migrated historical time data remains in the custom field. The User reference on the Time Entry maps to the Asana User via email matching.

farmerswife stores files in a server-side files folder referenced by Project. We catalogue all file references, reconstruct folder paths from the farmerswife server directory, and remap them as Asana Attachments on the relevant Project or Task. Files over 100 MB cannot migrate via the Asana API and are flagged with the original file path for manual re-upload. The customer's IT team provides the files folder during scoping, and we map attachment references in bulk.

farmerswife Custom Fields added to Projects, Objects, Activities, and other entities migrate to Asana custom fields on the equivalent entity. We preserve field type (text, numeric, date, dropdown) by mapping to the closest Asana custom field type. Dropdown options become Asana enumerations. Because each customer's farmerswife Custom Field schema is unique, we perform field-level discovery during scoping and generate the destination custom field schema before any data import begins.

farmerswife Classes are categorical labels used to group Activities, Objects, and Projects (e.g. 'TV Production', 'Commercial', 'Post-Production'). We map Classes to Asana Tags attached to the relevant Project or Task. Multiple Classes on a single record migrate as multiple Tag assignments. The customer chooses whether to preserve the full Class taxonomy or consolidate during scoping.