Project Management migration
Field-level mapping, validation, and rollback between Function Point and Jira. We move data and schema; workflows are rebuilt natively in Jira.
Function Point
Source
Jira
Destination
Compatibility
11 of 13
objects map 1:1 between Function Point and Jira.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Function Point to Jira is a significant category shift: Function Point is an all-in-one agency management platform with CRM, time tracking, Estimates, and Invoices; Jira is an issue-tracking and agile planning tool built for software development teams. We migrate the structured project and task data that both platforms share — Projects, Jobs, Tasks, Timesheets, and Contacts — and we explicitly flag the financial layer (Estimates, Invoices, Expenses, Rate Schedules, and Service Groups) that has no Jira equivalent, so your team can plan a parallel billing workflow or accounting migration before cutover. Function Point's REST API excludes custom fields on Companies and Contacts entirely, which means any custom Company or Contact attributes require manual CSV export and manual entry at the destination. Jira workflows, automations, and sprint boards do not migrate; we deliver a written inventory of these for your admin to rebuild in Jira.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Function Point object lands in Jira, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Function Point
Project
Jira
Project
1:1Function Point Projects map directly to Jira Software Projects. Each FP Project becomes a Jira project, preserving the project name, status (Active/On Hold/Complete), start and end dates as Jira Project dates, and budget fields as custom fields in Jira. If the FP Project has an On Hold status, we set the Jira project to archived or restrict access via permission scheme rather than deleting.
Function Point
Job
Jira
Epic
1:1Function Point Jobs map to Jira Epics within the target Project. FP Job fields — job number, status, owner, cost codes, and description — map to Jira Epic fields. The Epic summary carries the Job name, and the Epic description carries the Job description. Parent-child linkage from Job to Project is preserved as the Epic-to-Project relationship. Jira Epic Link custom field connects child Stories (from FP Tasks) to the parent Epic.
Function Point
Task
Jira
Story or Subtask
1:1Function Point Tasks map to Jira Stories, with the FP Task name as Story summary, description preserved, and status mapped through a value translation table. Custom Task labels in Function Point map to Jira labels or a custom field. If the FP Task has subtasks, these map to Jira Subtasks nested under the parent Story. Jira story points can be estimated if the team uses them; otherwise the FP estimated hours map to a custom field.
Function Point
Timesheet
Jira
Worklog (via custom fields on Issue)
1:1Timesheet entries (user, date, hours, Job/Task association, billable/non-billable flag) are among the most valuable historical records to migrate. Jira Software Premium ($18.30/user/month) has native time tracking with worklogs on issues. For Jira Standard, we create a custom field set on the Story: fp_timesheet_user (text), fp_timesheet_date (date), fp_timesheet_hours (number), fp_billable (checkbox). We link each timesheet entry to the Jira Issue derived from the parent FP Task or Job. Jira Premium customers can use the native worklog model instead.
Function Point
Company
Jira
Project or custom Contact field
lossyFunction Point Companies can map to Jira in two ways depending on your use case. For Jira Software customers who work with clients inside Jira, we create a Jira Project per client Company and link FP Company address and rep fields to project metadata. Alternatively, we create a custom field fp_client_name__c on the target Issues and populate it from FP Company, noting that Jira has no native CRM. FP Company phone, website, and address fields map to Jira project description or a Jira Issue custom field. We cannot retrieve FP Company custom fields via the API.
Function Point
Contact
Jira
Issue Assignee or custom field
lossyFunction Point Contacts attach to Companies and carry name, email, phone, and role. In Jira, there is no Contact object. We map FP Contact to the Jira User (Assignee) where the FP Contact email matches a Jira user email. If no match exists, the Contact becomes a custom text field fp_contact_name__c or fp_contact_email__c on the Issue. FP Contact notes migrate as Jira Issue comments or a custom long-text field. We cannot retrieve FP Contact custom fields via the API.
Function Point
Brief
Jira
Issue description or Attachment
1:1Function Point Briefs hold project creative direction and scope documents as free-text content. Briefs export via CSV or API as unstructured text. We map Brief text to the Jira Issue description field of the Epic (FP Job) or a parent Story. If the Brief contains file attachments, we migrate them as Jira Issue attachments via the Jira API. The Brief-to-Jira mapping is content-dependent; long-form briefs may require chunking across multiple description updates or storage in Confluence as a linked document if Jira description length is exceeded.
Function Point
Estimate
Jira
No direct equivalent — Jira Story estimates only
1:1Function Point Estimates contain line items with service names, quantities, rates, markups, and totals linked to Projects. Jira has no native Estimate or quote object. We preserve the FP Estimate as a Jira Story with a custom field set: fp_estimate_total__c (currency), fp_estimate_markup__c (number), and a description block listing the estimate line items as a text table. For agencies that need precise financial Estimates, we recommend maintaining a separate estimating tool (QuickBooks, Honey, or a spreadsheet) and linking the Jira Story to the estimate via a custom URL field. This is a known gap that requires workflow planning before migration.
Function Point
Invoice
Jira
No equivalent in Jira
1:1Function Point Invoices (Draft and Posted) have no Jira equivalent. Jira Software is an issue-tracking tool, not a billing system. We do not migrate Invoices to Jira. For Draft invoices, we identify the count and total value during scoping and provide a manual-recovery spreadsheet: FP Invoice number, client, date, amount, and status for entry into your target billing system. For Posted invoices already synced to QuickBooks, we recommend verifying the QuickBooks sync is active and that no additional Invoice records need manual handoff. Function Point's IIF export can be used to push posted invoices directly to QuickBooks before or after migration.
Function Point
Expense
Jira
No equivalent in Jira
1:1Function Point Expenses (vendor, amount, date, description, Job/Project link) have no Jira equivalent. Jira Software does not support expense logging or vendor tracking. We flag all FP Expense records during scoping with a count and total spend. For teams that need to track project spend against Jira Stories, we can create a custom Jira field fp_expense_amount__c on the Issue and link it to the Jira Story derived from the parent Job, but this is a partial workaround for visibility only — it does not replace an expense management or accounts payable system.
Function Point
Service Groups and Services
Jira
No equivalent in Jira
1:1Function Point maintains a service catalog (Service Groups containing Services with rates) used in Estimates. Jira has no native service catalog or product catalog for creative services. We export the FP service catalog as a spreadsheet during migration, noting service name, unit, rate, and markup. The customer uses this spreadsheet to configure products in a separate billing tool or to populate Jira custom fields on Stories where service-line visibility is required. This catalog export is delivered alongside the migration data package.
Function Point
Rates and Markups
Jira
No equivalent in Jira
1:1Function Point per-user and per-role rate schedules with markup percentages have no Jira equivalent. Jira does not model billing rates. We extract the full FP rate table during scoping and deliver it as a custom mapping spreadsheet for the customer's billing or finance team to configure in their target system (QuickBooks, Honey, or another estimating tool). The rate table export adds one to two business days to the migration timeline and is delivered before the Jira data import begins.
Function Point
Custom Fields (Companies and Contacts)
Jira
N/A
1:1Function Point's REST API explicitly excludes custom fields on Companies and Contacts. Any custom fields created in Admin > System Set Up for these objects are not readable via the API. We cannot retrieve or migrate these values programmatically. During scoping, we identify every custom field on Companies and Contacts and provide a manual-recovery plan: we export the data via CSV from the FP Find Companies and Find Contacts pages, and we assist with manual entry into Jira custom fields post-migration. This is a high-severity limitation that requires customer participation and is flagged in the gotchas section.
| Function Point | Jira | Compatibility | |
|---|---|---|---|
| Project | Project1:1 | Fully supported | |
| Job | Epic1:1 | Fully supported | |
| Task | Story or Subtask1:1 | Fully supported | |
| Timesheet | Worklog (via custom fields on Issue)1:1 | Fully supported | |
| Company | Project or custom Contact fieldlossy | Fully supported | |
| Contact | Issue Assignee or custom fieldlossy | Fully supported | |
| Brief | Issue description or Attachment1:1 | Fully supported | |
| Estimate | No direct equivalent — Jira Story estimates only1:1 | Fully supported | |
| Invoice | No equivalent in Jira1:1 | Fully supported | |
| Expense | No equivalent in Jira1:1 | Fully supported | |
| Service Groups and Services | No equivalent in Jira1:1 | Mapping required | |
| Rates and Markups | No equivalent in Jira1:1 | Mapping required | |
| Custom Fields (Companies and Contacts) | N/A1:1 | Not supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Function Point gotchas
Custom fields on Companies and Contacts are API-inaccessible
No API delete operations means relational cleanup must go through CSM
Invoice migration requires separating Posted from Draft records
API access requires an active CSM relationship and developer resources
Rate and markup schedules require custom mapping to destination billing models
Jira gotchas
Unsupported workflow validators silently skipped during migration
Custom fields converted to flat text labels when migrating to non-Jira platforms
Historical status-change timestamps lost when exporting without a Marketplace plugin
Attachment import failures from oversized files and JQL reference corruption
Points-based API rate limits enforced on Jira Cloud apps from March 2026
Pair-specific challenges
Migration approach
Discovery and Jira edition selection
We audit the source Function Point instance: we identify all Projects, Jobs, Tasks, Timesheets, Companies, Contacts, Estimates, Invoices, Expenses, and Briefs; we confirm which FP tier is active and whether API access has been enabled through the CSM; we identify custom fields on Companies and Contacts via manual CSV export; and we assess the financial layer volume for parallel migration planning. We pair this with a Jira edition recommendation: Standard ($9.05/user/month) for teams without native time tracking needs, Premium ($18.30/user/month) for teams that require native worklogs and advanced roadmaps. The discovery output is a written scope with a clear list of what migrates to Jira, what exports as a spreadsheet, and what requires a parallel system.
Jira schema design and project structure
We design the Jira destination schema: we create one Jira Project per Function Point Project (or a smaller number of consolidated projects if the FP instance has many small projects); we configure the Jira issue type scheme (Epic, Story, Subtask, Bug, Task) based on the FP Job and Task structure; we create custom fields for timesheet data on Standard Jira plans and for any FP data that has no native Jira equivalent (client name, expense amount, estimate total); we define the Jira workflow (To Do, In Progress, In Review, Done or equivalent) matching the FP status values. All schema is deployed to a Jira Sandbox first for validation before production configuration begins.
Function Point data extraction and deduplication
We extract data from Function Point via a combination of REST API endpoints (where available) and CSV exports from the module Find pages. We extract Projects, Jobs, and Tasks via API in dependency order (Projects first, then Jobs, then Tasks) to preserve parent-child relationships. Timesheets export via API with Job and Task associations. We extract Companies and Contacts via CSV for manual custom field recovery. Estimates, Invoices, and Expenses export as spreadsheets for parallel billing migration. We deduplicate records where the same entity appears under multiple names and flag duplicates for customer review before import.
Sandbox migration and reconciliation
We run a full migration into a Jira Sandbox using production-like record volumes. The customer's project manager and Jira admin review 25-50 randomly sampled issues from the FP Task migration, checking field accuracy, parent-child linkage, and sprint grouping. Any mapping corrections (field names, status value translations, Epic-to-Job assignments) are documented and applied to the production migration script. The sandbox sign-off is a prerequisite before production migration begins.
Production migration in dependency order
We run production migration in this order: Jira Projects (from FP Projects), Jira Epics (from FP Jobs), Jira Stories and Subtasks (from FP Tasks), Timesheet data (custom fields or native worklogs depending on Jira plan), Briefs (as issue descriptions or attachments), and Contact-to-Jira-User linkage (by email match). Estimates, Invoices, Expenses, Service Groups, and Rates are delivered as spreadsheets for parallel migration to a billing tool and are not imported into Jira. Custom field recovery for Companies and Contacts happens in parallel as manual entry guided by our CSV export. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze Function Point writes during cutover, run a final delta migration of any records modified during the migration window, then enable Jira as the system of record for project and task tracking. We deliver the Workflow and automation inventory document to the customer's Jira admin for rebuild. We support a five-business-day hypercare window to resolve reconciliation issues raised by the team. We do not rebuild Function Point workflows as Jira automations or Jira projects as Confluence spaces inside the migration scope; these are separate engagements.
Platform deep dives
Function Point
Source
Strengths
Weaknesses
Jira
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Function Point and Jira.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Function Point: Not publicly documented in public-facing help articles; rate limits are not disclosed on the API documentation portal.
Data volume sensitivity
Function Point doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Function Point to Jira migration scoping. Not seeing yours? Book a call.
Walk through your Function Point to Jira migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Function Point
Other ways to arrive at Jira
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.