Migrate from farmerswife to Jira

farmerswife Projects map to Jira Projects as the top-level container. Each Project's standard fields (name, status, dates, client link) map to Jira Project metadata fields. If the farmerswife Project contains high-level Activity groupings that need a parent-level aggregation in Jira, we create a single Epic per Project to act as that grouping container, and Activities become Stories or Sub-Epics within it. Custom fields on Project migrate to Jira Project Properties or to a custom field on the Epic.

farmerswife Clients map to Jira Projects when the customer's Jira configuration uses Projects as client containers rather than as production-work groupings. The Client name becomes the Project name, and we add a Client custom field (Jira custom text field) to preserve the original farmerswife Client ID for audit and cross-reference. If the customer instead uses Jira Projects as work groupings and Companies are tracked separately, we map Client to a Jira Company-typed custom field.

farmerswife Activities (scheduled work items within a Project, often representing shoot days, edit sessions, or production phases) map to Jira Epics. If the Activity contains sub-tasks or Bookings that need finer granularity, we create the Epic and nest individual Bookings as linked Stories or subtasks. The Activity dates (start, end) map to the Epic's start and due dates. Activity status (scheduled, in-progress, completed) maps to the Jira Epic Status via a configured workflow.

farmerswife Bookings represent resource assignments within Activities: each Booking links a Resource or Object to an Activity at a specific time slot. We map each Booking to a Jira subtask linked to the parent Epic (Activity). The resource reference (which Object or Person is booked) becomes the Jira Assignee or a custom Object Type label. Multiple Bookings for the same time slot within one Activity produce multiple Jira subtasks under the same Epic. We preserve the booking time window in the subtask description and in a custom date-range field.

farmerswife People (contacts, crew members, staff) map to Jira Users. We export the full contact details from farmerswife's People Object Type (name, email, phone, role) and provision Jira user accounts by email. Any farmerswife People that do not have Jira accounts (e.g., freelance crew without Jira logins) are stored as Jira Contact custom fields on the relevant Issue rather than as full Jira Users.

farmerswife Resources (equipment), Rooms, and Services do not have direct Jira equivalents because Jira tracks work items, not physical inventory. We map these to Jira Labels (e.g., Label: equipment_01, Label: studio_a) plus custom fields (Equipment custom field, Room custom field) on the relevant Issue. If the customer has a large equipment inventory, we recommend a Jira Asset Management ( formerly Insight) configuration as a separate engagement post-migration.

farmerswife Object Types (Crew, Equipment, Studio, Service) are broad categorical labels organizing Objects. Jira has no equivalent Object Type taxonomy. We map Object Types to a Label prefix (e.g., Type_Crew, Type_Studio) applied to all Issues referencing Objects of that type, and optionally to a custom single-select or multi-select field if the customer prefers structured categorization over Labels.

farmerswife Budgets with per line-item Price Agreements have no native Jira equivalent. Jira does not support a budget or cost-tracking object model without a third-party app. We migrate the budget total as a custom currency field on the Project or Epic, and we export all line items with Price Agreement details as a structured custom-field block or attached JSON payload. The customer reviews these during UAT. We flag this as a rebuild scope: either Jira custom fields plus a manual cost-entry workflow, or an AppExchange/Atlassian Marketplace budgeting app (Tempo Budgets, Structure Financials) as a separate implementation.

farmerswife Rate Cards (Client Rates and Project Rates with day rates, overtime, and custom pricing tiers) do not map to any Jira standard object. We export the full Rate Card structure including all rate tiers and permission assignments, and store it as a structured custom-field payload on the Project or as an attached reference document. The multi-layer rate permission hierarchy (who can view Project Rates vs Client Rates) has no Jira equivalent; we deliver a written rate permission inventory specifying the original permission matrix for the customer's admin to configure via Jira permission schemes.

farmerswife Users with role-based permissions (Project Rates Permissions and Client Rates Permissions) map to Jira Users with Jira Permission Schemes and Project Roles. The farmerswife permission hierarchy (Always Allow, default to own Projects, specific rate visibility) maps to a Jira permission matrix that we define during scoping. We note that Jira's permission model is role-based at the project level rather than field-level; customers requiring granular rate-field visibility need a custom field permission solution or an app like ScriptRunner.

farmerswife Custom Fields on Projects, Objects, and Activities map to Jira custom fields. We perform field-level discovery during scoping, identify the Jira field type equivalent for each farmerswife field (text, number, date, select, multi-select, user picker), and pre-create the Jira custom fields before migration. Since each customer's Custom Field schema is unique, we run field-by-field type mapping and validate data compatibility (e.g., multi-value custom fields in farmerswife map to Jira multi-select picklists).

farmerswife Time Entries (logged against Activities and Bookings) map to Jira Worklog entries on the relevant Issue. We preserve the original duration, date, and user reference by resolving the farmerswife time entry owner to the Jira User. Worklog ordering reflects the original farmerswife timestamp. Jira's time-tracking feature must be enabled in the target project before migration.