Most platform migrations are a leap of faith. You scope the work, budget it, pick a cutover date, and commit. The first time you see whether the new shape actually fits your data is after everything has already moved. If the model is wrong, you find out late, when fixing it is expensive.
We took a property management client through a different sequence.
The work
The client runs BC strata and rental property management on a long-standing Monday.com setup. The plan was to move to Jira Service Management: different platform, different data model, different admin tools. The kind of project that usually starts with weeks of learning the destination before anyone can say what the result will look like.
Instead, we prototyped the migration first. 1,500+ real records across 9 record types, including properties, units, owners, tenants, tenancies, and strata plans, moved into a working JSM instance with the cross-references between them wired up. Not synthetic test data. The client's actual records.
How it worked
We paired an AI agent with the client's own logged-in browser session. No API tokens were issued, no service account was created, no integration was built. The agent worked inside the session an admin was already in, using the same internal calls the admin tool fires when you click through it. It only ever did what that admin could already do, with the team present, and nothing was wired in that outlived the session. The bulk work, the records and fields and mappings and relationships, moved without anyone opening a screen.
Where the platform didn't expose something cleanly, we paired directly. Jira's workflow editor, for example, can't take certain changes through a script. So an admin opened the screen, the agent suggested the next step, the admin clicked, and we read what happened together. A gap like that used to stall a project. Here it was a short pairing session.
The thinking still happened upstream. The schema, the migration plan, and the trade-offs were worked through and agreed with the client's team before the agent touched anything. Skip that and the agent confidently builds the wrong thing. The agent executes against the plan, it does not replace it.
Why it changed the project
Because real data went in early, the client's team stopped reviewing in the abstract. They opened their own records and said "this is wrong" or "these two should be linked." The usual "pretend the real data looks like this" phase, where stakeholders sign off against synthetic records and the real data reveals every gap after cutover, did not happen.
They were also seeing their own operation in a way they never had. Their Monday setup held relationships as text references buried in cells. In JSM, the same records rendered as a graph they could see and click through, every connection between a property, a tenancy, an owner, a strata plan made visible. That view was new to them, and it changed how they read their own data.
And because the prototype was cheap to build, it stayed cheap to change. The team flags something, we rebuild it the same day.
Where it stands now: the client's team is working in their own prototype, checking it against how they actually operate. What's left is finalizing their records and finishing one workflow still in progress. Real work, but not a rebuild.
The honest boundary
A prototype is not a migration. Cutover, change management, and training are still ahead, and those are real work. But the build cost and the change cost dropped to near zero, which moves the remaining risk off the technical unknowns and onto the people part of the project: adoption, training, sign-off. Which is where the risk should have been all along.
If you are sitting on a migration
If you have been putting off a platform switch because the learning curve and the integration build felt too steep to even start, that calculus has changed. We can show you the shape of your migration, with your real data, in the destination platform, before you commit to it.