Migrating from Pluralsight Flow: A Step-by-Step Guide
Migrating from Pluralsight Flow to a modern engineering metrics platform does not require data exports, complex imports, or weeks of implementation work. This guide covers exactly what to do before, during, and after the migration — and how to preserve your DORA baselines and team structure in the process.
This guide is written for teams migrating to Koalr specifically, but the preparation steps apply to any destination platform.
Before You Start: What to Capture
You do not need to export data from Pluralsight Flow — the destination platform will backfill from GitHub directly. What you do want to capture is configuration and baseline data that would otherwise require memory or guesswork to recreate.
1. Screenshot your current DORA baselines
Open your Pluralsight Flow DORA dashboard and screenshot or export your current numbers for deployment frequency, lead time for changes, change failure rate, and MTTR. Set the time range to the last 90 days. This gives you a before/after comparison point once your new platform is up and running.
Specifically capture: the per-team numbers (not just org-wide averages), and any trend lines that show how metrics have moved over the past quarter. These are the baseline you want to confirm are reproduced in the new platform.
2. Document your team structure
In Pluralsight Flow, teams are configured manually — engineers are assigned to teams that may or may not match your GitHub team structure. Before migrating, export or screenshot your team membership list from Flow's settings.
If your Flow teams match your GitHub organization teams, you're in good shape — most platforms can import from GitHub teams automatically. If you have custom groupings (e.g., "backend-platform" that spans two GitHub repos and five engineers from different GitHub teams), document those groupings explicitly.
3. List your custom reports
If you have custom dashboard views or scheduled reports in Pluralsight Flow, take note of what they show and who receives them. Most custom views in Flow are standard metric combinations (cycle time by team, review time trend, etc.) that the new platform will replicate natively — but knowing what you had prevents gaps.
The Migration: Step by Step (Koalr, Under 30 Minutes)
Sign up for Koalr and install the Koalr GitHub App on your GitHub organization. Grant access to the repositories you want to track — you can add more later. Koalr immediately begins backfilling 90 days of PR history. By the time you finish the next step, your historical data will be partially or fully populated.
Authorize Koalr to access your Jira instance via OAuth. Koalr will discover your projects and begin linking issues to PRs using branch name conventions (e.g., PROJ-123 in branch names or PR titles). This is the same linkage logic Pluralsight Flow uses — most mappings appear automatically without manual configuration.
In Koalr's team settings, create teams matching the structure you documented from Pluralsight Flow. If your teams match GitHub teams, use the GitHub team import — it populates membership in one click. For custom groupings, add engineers individually. A 10-person team takes about 2 minutes to configure.
Add engineering managers and engineers by email. Managers get team-level visibility by default; engineers see their own metrics. Role configuration takes about 1 minute per person. If you're running a pilot, start with just your EM team before opening access to all engineers.
Compare Koalr's DORA numbers against the screenshots you took from Pluralsight Flow. Minor differences in deployment frequency are normal if your deploy tracking method differs (Koalr uses GitHub deployment events; Flow may have used a different signal). Lead time and cycle time should match closely.
After the Migration
Once your DORA baselines are verified and your team structure is set up, three things activate automatically in Koalr that were not available in Pluralsight Flow:
- Deployment risk scores.Every PR opened in your connected repos receives a 0–100 risk score, calculated from 32 signals including change entropy, DDL migrations, SLO burn rate, and author file expertise. The score is posted as a GitHub Check on the PR.
- AI chat.You can ask Koalr questions in plain English about your engineering data: "Which service had the highest change failure rate this month?" or "Show me PRs with review time over 48 hours in the payments team."
- CODEOWNERS sync. Koalr reads your CODEOWNERS files and alerts when PRs are merged without required owner review.
Running Both Tools in Parallel
You can run Pluralsight Flow and Koalr simultaneously — they operate independently via the GitHub API and do not interfere with each other. Most teams run both for 2–4 weeks before cutting over: this gives engineering managers time to validate that the numbers match before canceling Flow.
If you have scheduled reports in Pluralsight Flow that go to VPs or CTOs, set up the equivalent in Koalr before canceling Flow. Koalr's report scheduler can send weekly or monthly metric summaries to the same distribution list.
Frequently Asked Questions
Do I need to export any data from Pluralsight Flow before migrating?
No. Koalr backfills 90 days of GitHub PR history automatically. The only things worth capturing from Flow before you cancel are your DORA baseline numbers and team structure, both of which are for your own reference rather than for import.
Will historical data before 90 days be available?
Koalr backfills 90 days on connect. For older history, GitHub API rate limits make longer backfills impractical for most organizations. If you need more than 90 days of historical data for trend analysis, contact our team — we can discuss options for specific high-value repos.
How do deployment frequency numbers compare between Flow and Koalr?
Pluralsight Flow uses GitHub deployment events (if configured) or merge-to-main as a proxy for deployments. Koalr uses GitHub deployment events by default. If your Flow numbers were based on merge-to-main, the deployment frequency number in Koalr may differ slightly — connect your deployment pipeline to emit GitHub deployment events for the most accurate comparison.
Can I migrate Linear teams if we use both Jira and Linear?
Yes. Koalr supports both Jira and Linear simultaneously. If you have some teams working in Jira and others in Linear, both can be connected and Koalr will link issues from both systems to PRs.
What if my team structure in Pluralsight Flow does not match my GitHub teams?
Create custom teams in Koalr with the same groupings you had in Flow. You can group any engineers from your GitHub organization into a Koalr team regardless of their GitHub team membership. Most teams complete this in under 15 minutes.
Ready to migrate?
Start your free Koalr trial and be fully operational in 30 minutes. Or book a migration call and we'll walk through it with you.