There is a feature you want to try in a new UE. But you would rather not break the game that currently works. In that case, before updating your in-progress data directly, open a copy in the new UE and test it .
What matters is more than whether the editor launches. The character moves, doors open, you can reach the results screen. Try the same actions that used to work and confirm all the way through producing a distributable build.
This article uses UE installed via the Launcher and runs through preparing to preserve the pre-update state, converting a copy, and comparing behavior. Set up a state where, even if problems appear, you can keep working with the original project and the older UE.
What You'll Learn
- Reasons to update and how to confirm plugin support
- Preserving the original data and testing with Open a Copy
- What to compare across logs, Blueprints, Play, and packaged builds
- Where to investigate when problems appear and how to resume work
Upgrade or wait?
A new version existing does not mean an in-progress project must update immediately. Start by writing "what am I upgrading for" in one line.
| Reason to consider updating | What to confirm first |
|---|---|
| There is a new feature you want | Whether your game uses it and whether the required environment is available |
| You want a bug you hit fixed | Whether that bug is fixed in the target version |
| You need support for a platform | Which version meets its OS and toolchain requirements |
| You want to align the team's setup | Whether everyone can install the same UE and plugins |
Release notes list what changed and what was fixed in a version. Beyond new feature announcements, check changes to features you use and any "Upgrade Notes". Rather than reading everything, starting from areas relevant to your game — input, rendering, animation — reads more easily.
Late in production, the time available to verify afterwards matters too. When the benefit is small and you can ship on your current version, testing after completion is a valid choice. Conversely, with a deadline-driven reason such as platform support, schedule the migration and verification time.
Check plugins whether free or paid
A plugin adds features to UE. When your project uses one, updating UE itself does not necessarily make it behave the same.
Check what you use in "Edit → Plugins" and note names, current versions, and support for the target version. Look up supported versions and installation steps on Fab or the developer's page. Plugins installed on the engine side do not move to the new UE by copying the project folder alone.
If an essential plugin has no supported version yet, you need time to wait or to try an alternative. Unsupported plugins are not all disabled automatically; opening the project can stop outright.
What to preserve before upgrading
Your fallback when trouble appears after updating is the combination of the pre-update data and a UE that opens it . Play in the current version first, confirm it works, and save with "Save All".
Using source control, commit here. A commit records that moment's changes into history. Files outside source control are not preserved, though. Confirm you have what you need, including the actual data of LFS-tracked assets (see the Git management article).
| What to keep | Why |
|---|---|
| The whole project | Content, Config, and the .uproject plus the Source, Plugins, and Build you use |
| Old UE and plugin information | So you can reopen and compare in the original environment |
| Needed data outside the project | External assets and tools are not included in a project copy |
| Notes and screenshots of behavior | So you can separate pre-existing problems from new ones |
Close the editor, copy the project folder elsewhere, and keep it as a backup. Then update the verification copy created by "Open a Copy" below. Your disk needs room for the original, the copy, the new UE, and the generated files from working.
Do not wipe Saved wholesale
Saved can hold autosaves and game save data as well as logs. UE can recreate the folder, but that does not bring back what was inside. There is no rule requiring deletion before updating.
Intermediate is mid-build data and DerivedDataCache is reusable converted data. Regenerating them for investigation happens, but proceed without deleting at first. Excluding something from Git is also separate from whether you can delete it locally (see initial settings and what to keep).
Open the copy in the new UE
Install the target UE from "Unreal Engine → Library" in the Epic Games Launcher. Keeping the old version is fine. Using C++ or code-based plugins also means preparing the development tools the target version supports.
Here we use Open a Copy , which has UE make the copy.
- Launch the target version's UE from the Launcher.
- Select the original project in the Project Browser. If it is not listed, specify the
.uprojectvia "Browse". - Choose "Open a Copy" on the confirmation for opening a project from another version.
- Wait for the copy and conversion. Once open, confirm the project you are working in is saved somewhere other than the original. Right-clicking in the Launcher's project list and choosing "Show in folder" reveals the location.
"Convert in-place" converts the original project where it is. Our procedure chooses Open a Copy. If a setting opens an existing project automatically, reselect via "File → Open Project".
The first run can take time preparing shaders and the like. Watch progress and the log, and keep any displayed errors when conversion fails.
Switching a copy you made yourself
On Windows, you can also right-click the copy's .uproject and choose an installed UE with "Switch Unreal Engine Version". That specifies which UE opens that project . It does not automate creating the copy or verifying behavior.
It also does not revert updated assets to an older format. Pointing back at an older UE does not undo the update. To go back, open the preserved pre-update data with the old UE.
Once it opens, compare against the previous behavior
Check the log and Blueprints first, then move to actual controls. Compiling successfully means it assembled into a runnable form. It does not guarantee "the game's rules are as before".
- Check Errors and Warnings in the "Output Log". When filtering finds something of concern, restore the surrounding normal logs and read around it.
- Confirm required plugins are available and there are no warnings about missing classes or assets.
- Open your main Blueprints and check errors and warnings via each "Compile". Fix problems from where the message points.
- Open the levels you use and try input, collision, screen transitions, and audio in Play. Compare against your pre-update notes.
- Run automated tests if you have them, and build a packaged version and operate it.
Rather than ignoring every warning or driving the count to zero for its own sake, confirm what each affects. Comparing against what appeared before the update narrows the scope.
Compare visuals at the same location, camera, and quality settings. When brightness changes, look at whether lighting, materials, or rendering settings produced the difference before reverting settings all at once.
How to investigate when problems appear
| Symptom | Clues to investigate | What to do next |
|---|---|---|
| Launching or conversion stops | Conversion errors, the copy's Saved/Logs, Crash Reporter | Check the named plugin, file, or development tool |
| A Blueprint fails to compile | That Blueprint's Compiler Results | Check missing functions, types, parent classes, and pin connections |
| "Deprecated" appears | The warning text and the target version's changes | Look up the recommended replacement and confirm behavior after changing |
| C++ will not build | The first specific compile error | Check supported compilers and SDKs and changes to function names and arguments |
| It works in the editor but not in the build | Packaging-time and runtime logs | Check included maps, assets, and runtime plugin support |
Deprecated is a notice that "you should move to another approach going forward". Some still work, and it does not mean "every red node is deprecated". Compiling also fails when required plugins or parent classes are missing.
If it opens with plugins missing, do not immediately re-save every asset. Restore the dependencies first so things load correctly. To disable features for isolation, test in a further separate verification copy.
Regenerate caches once logs or known issues show you need to. Close the editor, confirm what can be regenerated, and back it up. Some data, such as Binaries for plugins without source, cannot be rebuilt by you if deleted.
If resolution drags on, keep the verification copy and logs, open the original project in the old UE, and resume work. Deleting the failed copy is not a prerequisite for recovery (see how to read logs).
Hands-On: run one upgrade loop on a small project
For a first time, try a small Third Person project before your main production. The goal is not to cause a defect but to confirm you can verify the same result before and after .
1. Build markers for comparison
Create a Blueprint Third Person template in your current UE and name it UpgradePractice . Where a Variant is offered, use the basic "None".
- Keep the template's floor and Player Start and add one Cube in front of the character.
- Create
BP_UpgradeCheckvia "Blueprint Class → Actor". Actor is the base class for things placed in a level. - In the Event Graph, wire
Event BeginPlay's white exec pin intoPrint Stringwith In StringUPGRADE CHECK OKand Duration10.0. - Compile, save, and place one
BP_UpgradeCheckin the level. No visual components needed. - Play and confirm the text appears right at the start, the Cube is visible, and WASD moves and Space jumps.
BeginPlay fires at game start and similar moments. We confirm through text that our Actor is in the level and its logic runs. If you cannot see Print String's Duration, expand the details with the arrow at the node's bottom. Keep Print to Screen on.
Take a screenshot, stop Play, and save with Save All.
2. Update the copy and try the same things
Close the editor, make a backup, and move to the new UE using the Open a Copy steps above. Note the original's and copy's folders and the UE versions in use.
Once the copy opens, check the log and compile BP_UpgradeCheck and the template's character Blueprint. Then Play the same level and compare the following.
| What to check | Before the update | Expected after the update |
|---|---|---|
| The startup text | UPGRADE CHECK OK | The same text appears |
| The marker Cube | Visible where you placed it | Visible in the same place |
| WASD and Space | Movement and jumping work | The same controls work |
Matching without problems means the small project's update and comparison worked. For your own game, add checks to this table such as "20 damage to an enemy takes HP 100 → 80" and "you can retry from the results" (see the automated testing introduction).
3. Confirm the packaged build and your fallback
Package the copy in Development and confirm the text, Cube, movement, and jumping outside the editor too. Specify the level holding this exercise as the startup map. For distribution, also build Shipping and re-confirm movement and other controls. Print String is not used as a Shipping verification display (see the packaging steps).
Finally close the copy and open the original project in the old UE. The same exercise working confirms your fallback too. After a successful update, decide which one continues production so you do not make separate changes to both.
Bonus: moving to a version further away
Do I need to go one version at a time?
You do not necessarily go through every version. Investigate the target's compatibility and the important changes in the versions between, then test on a copy. When a distant jump makes causes hard to isolate, checking an intermediate version helps show where the difference appeared.
For big changes such as UE4 to UE5, consult the official migration guide alongside the normal update steps. Some features, such as physics and rendering, do not behave identically from data conversion alone.
When you want to bring new-version changes back to the old one
Work you added in the copy does not return to the original automatically. Do not assume updated assets can go straight into an older UE; record what changed and judge what you can rebuild in the old version. During verification, deciding which version you adopt before writing a lot of new-feature code keeps things tidy.
If you build the engine from source, engine-side changes and the build environment are also part of the migration. In addition to this article's Launcher-version steps, prepare a procedure suiting that development setup.
Summary
Confirm your reason to update and the plugins you need, preserve the original data and the old UE, then test on a copy. After it opens, do not stop at logs and compiling; compare the same controls, visuals, and packaged build as before.
Confirming both "it works on the new version" and "I can go back to the old one and continue" on a small exercise lets you follow the same order on your in-progress game.