Port or rebuild your legacy VR app?
Your 2019–2023 Quest app was built on Oculus SDKs Meta has deprecated in favour of OpenXR. Here is an honest comparison of porting it to Unity 6 and OpenXR versus building it again from scratch.
Short verdict
If you have the Unity source, the app still does its job and the content is still right, port it: you keep what you paid for and get onto a supported stack faster. If the source is gone, key paid assets can't be restored, or the design and learning content are out of date, rebuild: a port would only preserve the problem. When you're not sure, a short audit of the source settles it before you commit to either.
Port vs rebuild, side by side
| Aspect | Port to Unity 6 + OpenXR | Rebuild from scratch |
|---|---|---|
| Cost model | Fixed-price audit, then a fixed price for the port. You pay for migration work, not for recreating scenes and logic you already own. | A full new project: concept, 3D, development and testing are all paid again, even for the parts that worked. |
| Time to launch | Usually shorter, because scenes, models and logic carry over. The audit gives you the schedule up front. | Longer: discovery, design and production start from zero. |
| What carries over | Scenes, prefabs, scripts and content, with original asset IDs kept. Owned paid assets are restored from your licences. | Only what you choose to reuse as reference. Everything else is new. |
| Design and learning content | Stays as it was. If the original design or learning goals are outdated, a port preserves the problem. | Free to redesign the experience, the interactions and the learning path around today's goals. |
| Measurement | Whatever the original tracked, plus a usage dashboard we can add in the Run phase. | Analytics can be designed in from day one, around the KPIs you care about now. |
| Platforms | A current Unity 6.3 + OpenXR codebase; one repository can build several apps (for example Quest and Windows). | Any target you choose, including browser-first WebXR if headsets are no longer the main channel. |
| Main risks | Missing source, paid assets you no longer hold a licence for, or dependencies on discontinued SDKs. All of these surface in the audit. | Scope creep, a longer approval cycle, and losing details that worked well in the original. |
| Maintenance afterwards | On a supported stack, with an optional Run plan: device management, OS-update testing and content refresh. | Also on a current stack; maintenance still needs a plan, or it ages the same way. |
| When it's the better choice | The app still does its job, you have the source, and the content is still right. | No source, key assets can't be restored, or the design and content are out of date. |
When to choose a port
- You have the Unity project, or can get it from the original agency.
- Learners or customers still use the app, and the content is still correct: it just needs to keep running, take an update or reach a new headset.
- The paid assets it depends on are licensed to your company, so they can be restored.
- You want a maintainable codebase quickly, and plan to add new modules later rather than redesign everything now.
We know this path well because we took it ourselves: VR Express ported its own catalogue of 33 legacy VR projects to Unity 6.3 LTS with OpenXR and XR Interaction Toolkit, all compiling clean. Each client port then gets a device QA pass before handover, because compiling is not the same as working on a headset.
When a rebuild is the better call
Here is where rebuilding from scratch wins, plainly.
- The source is missing. If all you have is the installed app, there is nothing to port. The old app becomes a reference for the new one.
- Paid assets can't be restored. If the models, avatars or tools came from packs licensed to the old agency, or from SDKs and services that have been discontinued, large parts must be replaced anyway. Past a certain share, a clean rebuild costs less than patching.
- The design is out of date. If the learning goals, the brand, the processes shown or the interaction style no longer fit, porting preserves the problem. Rebuild around what learners need now.
- The channel has changed. If most of your audience should now reach the experience in a browser rather than a headset, a WebXR-first rebuild may serve them better than a ported headset app.
The third option: leave it in the drawer
Many teams do nothing, and for a while that works: Meta has said existing apps continue to function on Quest devices. The cost shows up later. The content you paid for stops reaching learners, the headsets age without management, and when something has to change, nobody can rebuild the project. If the app still matters, decide on purpose rather than waiting for an update to decide for you.
How we help with either choice
Our VR App Rescue & Run offer starts with a fixed-price audit, credited to the port. If the audit points to a rebuild, we say so and scope it instead; for new training builds see our VR training solutions and how we work.
Frequently asked questions
Is porting a legacy VR app always cheaper than rebuilding it?
Usually, because you keep scenes, models and logic you already paid for. But not always. If large parts depend on paid assets you can't restore, on SDKs that no longer exist, or on a design you want to change anyway, the port turns into a partial rebuild and a clean rebuild can be the better value. That is what the audit is for.
We only have the APK, not the Unity project. Can it be ported?
No. A port needs the source project. With only an installed build, the honest option is a rebuild, using the old app as a reference for content and flow. Check your contract with the original agency first: the source is often yours to request.
What happens to paid Asset Store packs in a port?
If your company holds the licence, we restore the pack in the ported project. If the licence was the agency's and can't be transferred, those models or tools are listed as missing in the audit, with options: buy a licence, replace them, or rebuild that part.
Can we port first and redesign later?
Yes, and it is often a sensible order. The port gets the app working on a supported stack quickly; new modules or a redesign can then be added on top of a codebase your team, or any vendor, can maintain.
How do we know which option fits our app?
Start with the fixed-price audit. It inventories the source, SDKs, packages and licences, tests the current build on your headsets and ends with a recommendation and a fixed quote. If a rebuild is the better call, the report says so.
Not sure which one your app needs?
Tell us what the app does, when it was built and what you still have. In 30 minutes we'll tell you whether a port, a rebuild or the audit is the right next step.