The Migration Checklist: 8 Questions Before, 10 Checks During, 5 Verifications After

1. Before You Start: Answer 8 Questions

All eight get answered before you open a .verse file. They produce no code, only decisions — and the expensive mistakes in a migration are always decisions, never typing.

• ▢ ① Which parts of this graph are gameplay logic? Art, animation, materials and editor tooling do not migrate. Circle off what you are not moving and the workload often halves on the spot.
• ▢ ② For each variable in the panel, does anything feed a Set node? The ones that do become var; the ones that do not, do not. Run Find References on every one — do not guess (Lesson 8).
• ▢ ③ Which variables have Instance Editable switched on? Those become @editable, and every one of them needs a default value decided up front (Lesson 22).
• ▢ ④ How many object / Actor references are there, and can they be None? This decides whether you use option or an @editable reference with a placeholder default (Lesson 18).
• ▢ ⑤ How many event entry points, and of what kind? Engine events, Event Dispatchers and custom events all land differently in Verse (Lesson 25).
• ▢ ⑥ How many Latent nodes are in the graph? Delay, Timeline, anything with the little clock in the corner. Each one drags along a decision about whether its host function needs <suspends> (Lesson 23).
• ▢ ⑦ Is there an Event Tick, and what is inside it? Tick logic usually needs a redesign, not a rewrite. Mark it and do not translate it literally yet (see this lesson's advanced extra).
• ▢ ⑧ Which other Blueprints does this graph depend on? Follow the references out one level and check whether migrating this drags half the project along. If you cannot draw a boundary, do not start.

With all eight answered you should be holding a small cheat sheet: this many vars, this many @editables, this many events, this many functions needing <suspends>. That cheat sheet is your translation plan — the rest of the work is typing it out.

2. While Translating: 10 Checks

These ten follow the order of the main lesson's six steps — check them as you write. Every one is mechanically checkable: no context needed, just a glance at the code.

• ▢ ① Class name and parent. BP_PascalCase becomes snake_case; the parent becomes the base class of your environment (today in UEFN that is creative_device).
• ▢ ② using lines. Every using is actually used; delete the ones that are not. Do not hoard them.
• ▢ ③ var, present and absent. Check against the cheat sheet: everything that should be var is, and nothing extra is.
• ▢ ④ @editable and defaults. Every eye icon landed as @editable, and every field has a default value (Verse does not accept empty fields).
• ▢ ⑤ Every Set node has a set. Then search in reverse: is there a bare X = Y anywhere that you wrote intending assignment? That is a comparison, not an assignment (Lesson 13).
• ▢ ⑥ Every Branch became a does-this-go-through check. logic got its ?, and failable calls live in places like if (Lessons 11 and 12).
• ▢ ⑦ Every Delay became Sleep, and the host wears the badge. Whenever you see Sleep or Await(), look up at the signature and confirm <suspends> is there (Lesson 23).
• ▢ ⑧ Every possibly-empty reference is accounted for. Either handled as an option or covered by an @editable with a placeholder default — no "it probably will not be empty" left lying around.
• ▢ ⑨ One event, one listening style. Subscribe and Await on the same event means one trigger wakes both sides and the logic fires twice (Lesson 25).
• ▢ ⑩ Inverted-polarity calls are wrapped. Enable / Disable, Show / Hide and anything else that reads backwards from the original is sealed inside a clearly named function.

That "search in reverse" in check ⑤ deserves its own emphasis: a missing set is hard to find because the error text says "failure context", which is one whole layer away from "you dropped two letters". Train the reflex — see failure context, go hunt for set — and you save a lot of time.

3. After Translating: 5 Verification Steps

Compiling is not the same as translating correctly — the compiler checks syntax, not whether you skipped an entire node. These five are ordered cheapest first:

• ▢ ① Compile. Build passes, zero errors. Read the warnings too; do not skip them out of habit.
• ▢ ② Tick off node by node. Put the original and the translation side by side and walk the cheat sheet square by square. Skipping a whole node is both the most common error and the hardest one for testing to catch.
• ▢ ③ Align the logs. Add a Print at every key branch, run it, and confirm the log order matches the original's execution line order. Log generously during a migration; trim before shipping.
• ▢ ④ Cover the paths. Test as many branch paths as the original has: Branch True and False, timeout and early, bound and unbound. Testing only the happy path is not testing.
• ▢ ⑤ Rehearse the edges. Deliberately leave an @editable reference empty and run it — is the failure mode really "pressed it, nothing happened"? Then set the duration to 0 and run again. You need to know what it looks like broken, not only what it looks like working.

One last rule: do not entertain refactoring until verification passes. A translation whose behavior matches the original is the reference frame for every optimization that follows; start changing things before the frame is steady and you will not even be able to say where to roll back to. When to refactor and into what belongs to this lesson's advanced extra page.

4. Quick Quiz