Two-way sync between a client portal and Jira

The challenge#

The client runs its security assessments through a customer portal, which is the system of record. Their assessors work in Jira. With no link between the two, people retyped the same data in both places, things fell out of step, and customers lacked visibility.

What I did#

I built and run a sync service that moves data in both directions while keeping the portal authoritative. It covers seven flows, from customer and work-item records to comments, assignments and cascades when a parent record changes. I also built a phased migration that brought historical records into Jira, always running in dry-run mode first.

How it works#

An API service polls the portal for changes and receives Jira webhooks. It puts work on a queue that a worker processes, so retries come for free. Every successful sync records a hash of what was written, so a repeated message, or an echo of our own change coming back, is recognised and skipped. Database advisory locks stop two cascades from updating the same records at once. The polling cursor is designed so that nothing is ever skipped and nothing is read from the future.

A reconciliation engine compares the two systems on counts, states, fields and orphaned records and repairs what has drifted. Field and workflow IDs live in per-environment configuration, so staging and production can differ safely.

Results#

• The portal and Jira stay in step automatically, in both directions.
• Assessors work in Jira without retyping portal data.
• Historical records were migrated in controlled phases.
• Drift is detected and repaired, not discovered by a customer.

What I learned#

Two-way sync fails in the gaps: duplicate deliveries, echoes and partial failures. Designing for idempotency first, and treating reconciliation as a feature rather than a cleanup script, is what made it hold up in production.