top of page

Unreal Engine Blueprint Conversion the Right Way

Updated: Jun 7

Help us, Bjarne Stroustrup. You’re our only hope.


Sourcify Unreal Editor splash screen

Blueprints are Unreal’s lingua franca, providing almost full engine power to scripters. But BPs must be managed carefully. What starts as rapid prototyping often metastasizes into thousands of nodes across a hundred interconnected BPs. When the time comes to Sourcify that web into performant native C++, most studios are left with only two options:

  • A painful, manual rewrite that breaks half the game.

  • Or doing nothing at all, because it’s too risky or too late.


We’ve been there too. And we decided there had to be a better way.


At Unreal Fest 2025 in Orlando, we shared the story of how we built an automated pipeline and toolset to convert Blueprints to C++ instantly, reliably, and without breaking the rest of your UE 5 project. The end result is Sourcify, an Unreal Engine 5 plugin. You can check it out right now by heading to our Downloads page.


This post breaks that process down for Unreal engineers who want to stop dreading the conversion process and start converting Unreal Engine Blueprints the right way.


The Problem: You Can’t Keep Living Like This

You already know how it goes:

  • Blueprints can become monolithic, slow, and impossible to diff.

  • They lock users out when using source control.

  • They contain hard references to other assets like structs, enums, art assets, and worst of all, each other.

  • But designers cannot stop working in them and producers struggle to justify a freeze of weeks or months to fix them!


And ironically, the hardest part is not writing the C++. The hardest part is fixing everything else.


We do this to ourselves. But the longer you wait, the worse it gets.


Conversion Constraints: The Ideal vs. The Real

Here’s what every team wants from a conversion:

  • Performance boost from native C++

  • No change in runtime behavior

  • No downtime for designers

  • No rework for QA

  • No refactors until engineering is ready


Many folks look to Core Redirects as the answer here. However, they only work in 3 narrow cases:

  1. Enum replacement

  2. Struct-to-struct swaps (with caveats)

  3. Full class replacement


Every other conversion: BP-to-native with partial migration, UPROPERTY mapping, event binding, component hierarchy, requires a manual process. That means error-prone refactoring, exclusive locks, and a lot of “uh oh” moments.


The Manual Reality: This Is Why You Drink

Converting even a simple BP involves:

  • Locking the BP and all its references

  • Creating a native parent class and porting over:

    • All UPROPERTIES

    • Functions (including OnRep and event dispatchers)

    • Components (with attachment rules and transforms)

  • Reparenting the BP and rebuilding nodes

  • Updating references in:

    • Other BPs

    • Maps

    • Widgets

    • INI files

    • DataTables

  • Hoping redirects work (spoiler: they won’t)


…and doing this over and over again.


Result: Weeks of tedium, dozens of regressions, and a team that never wants to touch conversion again.


Our Solution: Sourcify and Be Free

Instead of continuing this suffering, we decided to build a fully automated tool. One that:

  • Scans all dependencies from a selected asset

  • Generates clean, compile-ready C++ (with forward decls, metadata, etc.)

  • Updates every reference across the project

  • Preserves all default values, pin links, and behavior

  • Works in your existing UE5 setup with no engine changes required


We call the process Sourcification: Sourcifying a BP to C++ while keeping everything working exactly the same.


The Sourcification Pipeline – In Detail

When we say “automated Blueprint conversion,” we don’t mean a magic button that writes perfect game code. We mean a disciplined process that is not prescriptive but provides key insertion points for Engineers. These can be 1:1 function re-implementations or API refactors as part of a larger Engineering effort. Sourcify gets out of the way immediately. 


Here’s what each phase of Sourcify does.


1. Dependency Scan: Gather It All Up

Start by identifying everything the target Blueprint touches:

  • UserDefinedStructs, UserDefinedEnums, BlueprintInterfaces, and other BPs

  • Function/event references, property types, component classes

  • DataTable row structs

  • INI-configured references


Use UE’s reflection system to walk UCLASS, USTRUCT, UENUM, UPROPERTY, UFUNCTION metadata and build a full dependency graph.


2. Asset-Specific Context Data: Build the Data Model

For every type to be Sourcified, gather:

  • Code-safe names and metadata (DisplayName, Category, ToolTip, etc.)

  • Property specifiers and replication flags

  • Event dispatchers and function declarations

  • Component trees and attachment rules

  • Pin link data from Kismet


This model serves as your ground truth for code generation and restoration.


3. Code Builder: Emit Native C++ Code

Generate .h and .cpp files with:

  • Forward declarations, grouped headers, const correctness

  • Proper metadata: BlueprintType, Blueprintable, Category, etc.

  • Delegate declarations and constructor logic for components


4. Live Code Compile: Reflect Native Changes

Sourcify only offers Live Compile because we feel it’s that safe. Offline compile (or rather offering to stop at compile time) may be an option in the future.


5. Post Process: Use the Native Changes


Phase 1: Clean Out

  • Save BP and child BP CDOs

  • Remove all BP-defined variables, events, and components

  • Remove SCS nodes and rename conflicting archetypes

  • Reparent to native class and manually run constructor


Phase 2: Restore and Reassign

  • Rebind components and preserve hierarchy/transform

  • Reconnect delegate bindings

  • Replace Get/Set and function call nodes

  • Patch default values, CDOs, and archetype instances


In the end, all original behavior should be preserved with a clean native backing.


6. Reference Updater: Update the Whole Project

  • Scan Asset Registry for:

    • Maps, BPs, Anim BPs, Widgets, DataAssets, etc.

  • Replace:

    • Cast nodes with native equivalents

    • Macros/wildcard pins (reconnected for type deduction)

    • Enum usages with matched native values

  • Export/reimport DataTables

  • Gather up INI config references

  • Recompile all affected assets


7. Pin Link Restoration: Tell Kismet What You Did

Kismet tries to auto-fix broken pins, often incorrectly. We:

  • Destroy and recreate pins for modified properties

  • Use saved pin link data to reconnect

  • Handle split pins, renamed pins, illegal names, default values


Once done, BPs compile cleanly and behave exactly as before.


Resourcifying: Do It Again, and Again

One of the most powerful aspects of this pipeline is that it's repeatable.


By tagging generated C++ with custom metadata and maintaining asset context, we can safely resourcify Blueprints multiple times:

  • Designers make further changes in the BP

  • Sourcify reruns, lifting new logic or variables into native

  • All references and pin links are reprocessed


Even better: the Post Process and Reference Update phases don’t change. Only the Code Builder phase needs adjustment.


This gives teams the ability to evolve prototypes continuously and transition them into performant, maintainable native code without losing momentum.


Branching Derivatives: Native as a Base, BP as the Future

What if you don’t want to resourcify the same Blueprint forever? What if you want to branch it?


Our pipeline supports that too.

Example:

  • Convert BP_Enemy to AEnemy (native class)

  • Let designers iterate on BP_Enemy again

  • Later, promote that BP to BP_FlyingEnemy, which inherits from AEnemy


Now you have a branching derivative with clean native foundations and Blueprint flexibility on top.


This unlocks powerful workflows:

  • Native base classes for performance-critical paths

  • Designer-owned Blueprints for content customization

  • Fully automated promotion paths between them


And because Sourcification is repeatable, branching becomes a safe, expected step in the pipeline.


Press Play, Submit, Move On

After Sourcification:

  • Your Blueprint has a new native base class

  • Behavior is identical

  • All references are updated

  • Designers are unblocked

  • Engineers can re-architect when ready


You can even re-sourcify later. Add new BP changes, Sourcify again, or branch into new subclasses (BP_Enemy → BP_EvenNewerEnemy). It’s fast, reliable, and safe.


TL;DR: Build the Button for Unreal Engine Blueprint Conversion The Right Way

Manual conversion is slow, dangerous, and demoralizing. Sourcification, is fast, safe, and repeatable.


If your team Sourcifies BPs more than once, or just wants to maintain sanity during late-stage development, then you need a tool. Sourcify targets 30 to 90 seconds per run and aims to leave everyone happy:

  • Engineers get clean native C++

  • Designers keep their Blueprints

  • QA doesn’t notice

  • Production doesn't explode


Let Sourcify do the hard work now, so you can be lazy later. You deserve it.


Try Sourcify for free by heading over to the Downloads page.

Got questions? We’d love to hear from you. Hit us up on our Contacts page!

Comments


Commenting on this post isn't available anymore. Contact the site owner for more info.
bottom of page