Project Management migration

Migrate from Function Point to Jira

Field-level mapping, validation, and rollback between Function Point and Jira. We move data and schema; workflows are rebuilt natively in Jira.

Function Point logo

Function Point

Source

Jira

Destination

Jira logo

Compatibility

85%

11 of 13

objects map 1:1 between Function Point and Jira.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Function Point logo

Function Point

What's pushing teams away

  • The user interface is consistently described as dated and slow, with reviewers reporting 30-second load times for single records and multi-step processes that require ten or more clicks to complete simple actions.
  • The mobile app functions only as a time-entry device — users cannot view comments, interact with Tasks, or manage Projects from the mobile experience, making it unsuitable for field or remote-heavy teams.
  • Onboarding new users is reported as difficult, with the tool's depth creating a steep learning curve that requires significant internal training investment before team members become productive.
  • Reporting flexibility is limited to pre-built templates; users who need custom analytics must export to CSV and build reports in external tools, which breaks the in-app workflow for power users.
  • Agencies growing past 20–30 users report that the platform's performance degrades under concurrent load, with multiple users sharing what reviewers describe as a 'slow-loading spreadsheet' experience.

Choosing

Jira logo

Jira

What's pulling them in

  • Industry-standard tool with deep Git integration and sprint reporting that engineering teams already know, reducing onboarding friction for new hires.
  • Highly customizable workflows and status schemes let business teams model complex approval chains without writing code.
  • Strong ecosystem of Atlassian Marketplace apps means specialized capabilities like time tracking or portfolio management are one install away.
  • Free tier with up to 10 users and unlimited issues gives small teams a no-cost entry point to validate the platform before committing budget.
  • Visibility features — boards, backlog grooming, sprint reports, and dashboards — give leadership a shared view of what is planned, in progress, blocked, and done.

Object mapping

How Function Point objects map to Jira

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

maps to

Jira

Project

1:1
Fully supported

Function 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

maps to

Jira

Epic

1:1
Fully supported

Function 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

maps to

Jira

Story or Subtask

1:1
Fully supported

Function 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

maps to

Jira

Worklog (via custom fields on Issue)

1:1
Fully supported

Timesheet 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

maps to

Jira

Project or custom Contact field

lossy
Fully supported

Function 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

maps to

Jira

Issue Assignee or custom field

lossy
Fully supported

Function 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

maps to

Jira

Issue description or Attachment

1:1
Fully supported

Function 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

maps to

Jira

No direct equivalent — Jira Story estimates only

1:1
Fully supported

Function 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

maps to

Jira

No equivalent in Jira

1:1
Fully supported

Function 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

maps to

Jira

No equivalent in Jira

1:1
Fully supported

Function 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

maps to

Jira

No equivalent in Jira

1:1
Mapping required

Function 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

maps to

Jira

No equivalent in Jira

1:1
Mapping required

Function 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)

maps to

Jira

N/A

1:1
Not supported

Function 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.

Gotchas + challenges

What specifically takes care here

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 logo

Function Point gotchas

High

Custom fields on Companies and Contacts are API-inaccessible

Medium

No API delete operations means relational cleanup must go through CSM

Medium

Invoice migration requires separating Posted from Draft records

Low

API access requires an active CSM relationship and developer resources

Low

Rate and markup schedules require custom mapping to destination billing models

Jira logo

Jira gotchas

High

Unsupported workflow validators silently skipped during migration

High

Custom fields converted to flat text labels when migrating to non-Jira platforms

Medium

Historical status-change timestamps lost when exporting without a Marketplace plugin

Medium

Attachment import failures from oversized files and JQL reference corruption

Medium

Points-based API rate limits enforced on Jira Cloud apps from March 2026

Pair-specific challenges

  • Five Function Point objects have no Jira equivalent

    Function Point's financial layer — Estimates, Invoices, Expenses, Service Groups, and Rates and Markups — has no native equivalent in Jira Software. Jira is an issue-tracking and agile planning tool; it does not model billing rates, line-item quotes, vendor expenses, or posted invoices. We do not migrate these objects to Jira. We export them as spreadsheets and flag them for migration to a parallel accounting tool (QuickBooks, Xero, Honey, or a dedicated agency billing platform). Skipping this planning step before cutover leaves your team with a gap between project tracking and financial reconciliation.

  • Function Point API excludes all custom fields on Companies and Contacts

    Function Point's REST API documentation explicitly states that custom fields created in Admin > System Set Up for Companies and Contacts are not readable or writable via any endpoint. This is not a temporary limitation — it is a documented design exclusion. If your Function Point instance uses custom fields on Companies or Contacts, we cannot retrieve their values through the API. We flag all such instances during scoping, export the data via CSV from the module Find page, and assist with manual entry into Jira custom fields post-migration. This step adds one to two business days and requires customer participation.

  • Jira workflows, boards, and automations do not migrate

    Function Point workflows and Jira workflows are defined differently and are not interchangeable. Jira workflows are XML or JSON configuration files tied to project schemes, issue type screeners, and validators. We do not migrate them as code. We deliver a written inventory of every active Function Point workflow rule (triggers, conditions, and actions) mapped to a recommended Jira automation or Jira native feature, and the customer's Jira admin rebuilds them post-migration. Jira automations themselves (existing Jira rules) also do not transfer in a migration; we document them during scoping for manual rebuild.

  • Jira native time tracking requires Premium plan

    Time tracking in Jira Software is native only on the Premium plan ($18.30/user/month) via the Log Work button and worklog history on issues. Jira Software Standard ($9.05/user/month) has no built-in time tracking. We handle this by creating a custom field set on Jira Stories for Standard customers (fp_timesheet_user, fp_timesheet_date, fp_timesheet_hours, fp_billable). Premium customers can use the native worklog model. This difference must be confirmed during Jira edition selection before migration begins.

  • Jira CSV import fails silently on missing custom field context

    Jira custom fields have a context configuration that maps them to specific projects and issue types. During CSV import, if a custom field exists in the source data but its context does not include the target issue type, Jira silently skips the field value. We verify custom field context configuration before every Jira import batch. Jira Data Center Project Configurator migrations have a known issue where a missing custom field (referenced as customfield_XXXX) causes issue creation to fail entirely with a WorkflowException. We test custom field mapping in a sandbox before production import.

Migration approach

Six steps for a successful Function Point to Jira data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Function Point logo

Function Point

Source

Strengths

  • Comprehensive module set covering Projects, Jobs, Tasks, Timesheets, Expenses, Invoices, and CRM without requiring third-party integrations
  • Time tracking accuracy is a consistent differentiator, with granular logging per user per Job and billable/non-billable flags that feed directly into invoicing
  • Budget tracking at the Project level with threshold alerts gives agency owners proactive visibility into profitability before projects go over budget
  • Native QuickBooks integration exports posted Invoices and Expenses directly to an IIF file for import, eliminating double-entry for shops already on QuickBooks
  • Customer service scores are consistently high (4.5/5 on Capterra), with users citing responsive support staff and useful help-center documentation

Weaknesses

  • REST API excludes custom fields entirely — any migration involving custom Company or Contact data requires manual CSV extraction and manual entry at the destination
  • No API support for record deletion means data cleanup before or after migration must be coordinated with Function Point's Customer Success team
  • Mobile experience is severely limited to time entry only; teams expecting full mobile project management functionality will be disappointed
  • UI performance degrades under concurrent user load, making the platform increasingly frustrating as agencies scale past the 20–30 user range
  • Custom reporting requires CSV export to external tools; there is no built-in query builder or custom report designer for users who need ad-hoc analysis
Jira logo

Jira

Destination

Strengths

  • Deeply customizable workflows and status schemes with no hard limits on workflow complexity or number of custom statuses.
  • Strong agile ceremony support: sprint planning, backlog grooming, velocity tracking, and burndown charts for Scrum teams.
  • Industry-standard developer tool with native Git integration linking commits, pull requests, and deployments to issues.
  • Large Atlassian Marketplace with thousands of plugins extending time tracking, portfolio management, and reporting capabilities.
  • Free tier available for up to 10 users with unlimited issues, enabling evaluation before committing to a paid plan.

Weaknesses

  • Excessive configurability creates a steep learning curve; cross-team consistency is hard to maintain without strict governance.
  • Performance degrades with large backlogs, complex custom fields, and heavily nested issue hierarchies.
  • Reporting requires additional configuration or paid plugins; out-of-the-box analytics are limited for business users.
  • Jira lacks native sprint management, requiring Jira Software for true agile team features.
  • Teams outside engineering resist adoption due to UI complexity, leaving the all-in-one promise unfulfilled for cross-functional organizations.

Complexity grading

How hard is this migration?

Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Function Point and Jira.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Function Point: Not publicly documented in public-facing help articles; rate limits are not disclosed on the API documentation portal.

  • Data volume sensitivity

    B

    Function Point doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Function Point to Jira migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Function Point to Jira data migrations

Answers to the questions buyers ask most during Function Point to Jira migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between three and five weeks for accounts under 5,000 Tasks and 1,000 Projects with no custom field recovery scope. Migrations with high timesheet volume (over 50,000 entries), multiple Jira projects requiring separate issue type schemes, or a parallel QuickBooks billing setup for Invoice and Expense data move to six to ten weeks because of spreadsheet-based financial data handoff, Jira sandbox testing, and custom field manual-entry coordination.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Function Point.
Land in Jira, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day