Lua-in-Vim 9.0: backupcopy divergence for zero-downtime migration

Answer first

backupcopy=yes cannot preserve Lua-sourced edits or Lua state during a cross-platform migration, and there is no core Vim 9.0 :migrate command to use for zero-downtime hand-off. Lua state lives in memory and is lost on Vim restart. Continuous operation across a Vim restart on a different system is not supported by Vim itself; you must re-initialise Lua configuration and restore editor state from session/view files.

Confirmed facts

• backupcopy controls how Vim writes a file. With backupcopy=yes Vim copies the original file before editing and writes to the copy, which matters for external watchers and inode stability. It does not persist runtime state.
• Lua integration in Vim 9.0 is in-process. Lua globals, module state and any runtime modifications are volatile and are discarded when Vim exits.
• Vim 9.0 core has no standard :migrate command. Any :migrate is user-defined or plugin-specific and cannot be relied on for data safety.
• Session persistence is via :mksession and 'sessionoptions'. View persistence is via 'viewdir' and mkview. Both store window layout, cursor, folds and buffer list, not Lua runtime.

Likely explanation and platform divergence

backupcopy=yes helps avoid a truncate-then-write race for tools watching the file. On Unix the copy-then-rename pattern preserves inode expectations for some watchers. On Windows the copy semantics differ and Vim may use different write paths, so the observable effect is not identical cross-platform. Neither behavior affects Lua state retention.

Zero-downtime migration of a Vim-driven application is a mis-match: Vim is an editor, not a daemon. Restarting Vim on another host necessarily drops Lua state. The only portable artifacts are files on disk, session/view files, and your init.lua/vim9 script.

Steps needed for this case

1. Verify target build capability.

vim --version | grep -E '\+lua|\-lua'

If the target lacks +lua, any Lua-sourced configuration will fail on startup.

2. Do not rely on backupcopy for state. Use it only if you need stable file writes for external sync.

:set backupcopy?

3. Make configuration portable.
• Keep init.lua and Vim9 scripts in version control and source them on both hosts.
• On shutdown on source host: :mksession! /path/to/session.vim and :mkview for each buffer.
• On start on target host: :source /path/to/session.vim then manually re-source init.lua if session does not reload it.
4. Normalize paths. Session files store absolute paths. Use consistent mount points or adjust with :cd and path mappings before sourcing.

Missing diagnostic that changes recommendation: confirm the target Vim build is Vim 9.0+ with +lua and the same patchlevel as source. Without +lua you must fall back to Vim script, and without matching patchlevel Lua API differences can break plugins.