How Do You Plan and Sync Jira Work Across Two Instances with TeamBoard ProScheduler and Exalate?
This is Majid, Head of Support and Services at Exalate. This post is co-written with our partner at DevSamurai, makers of TeamBoard ProScheduler.
Jira holds your work well. Every task, story, and bug lives there as an issue. A list of issues isn't a plan, though. It doesn't tell you who's doing what, when it'll happen, or whether the timeline is even realistic.
Planning tools solve half of that. The other half shows up when the work you need to plan around doesn't sit in your Jira at all. Instead, it sits in a partner's, a client's, or a vendor's instance.
Here's how we've seen both halves get solved.
TeamBoard ProScheduler: building a plan on the work you can see
Jira is great at holding your work. Every task, story, and bug lives there as an issue. But a list of issues isn't a plan. It doesn't tell you who's doing what, when it'll happen, or whether the timeline is even realistic.
That's the gap TeamBoard ProScheduler fills. It sits on top of your Jira and turns the issues you already have into a plan you can see and act on.
Here's how that comes together.
Start with a board, not a backlog
The Schedule board is where planning begins. Your Jira issues show up ready to place; you drag and drop them onto a timeline and assign them to people. In a few minutes, a flat backlog becomes a clear picture of what's happening and who owns it. And because it's all drag-and-drop, adjusting is easy. When a task slips or priorities shift, you just move things around.
Plan around real capacity
A plan only works if people actually have time to do the work. ProScheduler shows each team member's capacity and current workload side by side, so you can spot who's overloaded and who has room. That helps you set deadlines you can hit, instead of ones you only hope to.
Keep the pieces connected
Most work has an order. Design before build, build before test. In the Gantt view, you can set dependencies between tasks so the sequence is clear. Turn on auto-scheduling, and when one date moves, the tasks that depend on it shift automatically. No manual reshuffling. You can also set milestones and baselines, so it's easy to see the big checkpoints and whether you're still tracking against your original plan.
See how it's going at a glance
As work progresses, dashboards and reports give you a simple read on project health. What's on track, what's slipping, and where attention is needed. Everyone stays informed without digging through individual issues.
Put together, ProScheduler gives you a plan that's visual, realistic, and easy to keep current, all built on the work living in your Jira.
And that last part is the key. ProScheduler plans beautifully around the work you can see.
But what happens when part of the plan lives in a Jira you can't see; in a partner's instance, on the other side of a collaboration? That's where the next piece of the puzzle comes in.
Exalate: when a part of the plan sits in another Jira
Here's the situation ProScheduler alone can't solve. The work you're planning around doesn't live in your Jira. It lives in a partner's, a client's, or a vendor's instance. You don't have a login, and you don't want one either. That's more license cost and more access for someone to manage on their end.
I see this a lot. A support desk needs to plan around a dev team's fixes, but the dev team works in a completely separate company's Jira. A client wants visibility into delivery dates that only exist in their contractor's backlog. The planning tool is ready. The data just isn't there yet.
Take a fairly common setup: an agency delivering a project for a client, where the client runs their own Jira and wants their PM tracking dates on their own board. The agency's dev team doesn't work in the client's instance, and the client's PM doesn't work in the agency's. Both sides still need the same dates to mean the same thing.
Exalate closes that gap. It syncs issues between two separate Jira instances in real time: fields, status, comments, dates, links. Neither side needs a login to the other's environment. When the other team updates a due date or moves a task, that update lands on your side as a normal field change on a normal issue. Nothing about it looks synced. It just looks current.
That's the part that matters for planning. ProScheduler builds its view from whatever's sitting in your Jira. It doesn't care whether an issue was created by a teammate or by a sync. If the dates and status are accurate and current, ProScheduler treats it like any other issue on the board.
So the flow looks like this. The partner updates their side. Exalate carries that update into your instance. ProScheduler picks it up and puts it on your timeline, next to everyone else's work.
You get a plan built from your team's work plus the parts that live somewhere else, without chasing updates over email or asking for a Jira license you don't need.
One thing worth being clear on. Each side keeps its own Jira, its own permissions, its own planning tool. What crosses over is the data, the fields your plan actually runs on.
You also control what crosses over, at the field level. Most teams syncing for planning purposes only need a handful of fields: due date, status, assignee, maybe a sprint or fix version. You don't have to sync comments or internal notes just to get a working timeline. That keeps the setup narrow on purpose, since the partner's Jira usually holds plenty that has nothing to do with your plan.
That's usually the setup people want anyway. Nobody's asking a partner to open their whole project to your team. They're asking for the dates to be right.
Before you go
Two separate problems, same shape. ProScheduler turns issues into a plan you can act on. Exalate makes sure the issues include work that isn't yours to begin with.
Neither one needs the other to work. Together, they mean your plan isn't missing the half that lives outside your Jira.
If you've got a version of this - planning around work that isn't in your own Jira - I'd be curious how you're handling it today. Drop it in the comments.