Your services run a dozen pieces of Lua logic on Redis via EVALSHA with a NOSCRIPT fallback, and the servers were just upgraded to Redis 7. How would you decide whether to migrate that logic to Redis Functions, and how would you carry out the migration?

## Frame the decision, not the syntax The rewrite itself is mechanical: `KEYS`/`ARGV` globals become the `keys`/`args` parameters of a registered callback, the file gains a `#!lua name=…` shebang, and `EVALSHA <sha> n …` becomes `FCALL <fname> n …`. The judgment is about whether server-side code should become a **deployed artifact** in your architecture. ## Where Functions genuinely pay **The NOSCRIPT tax disappears.** With EVALSHA every client must carry the source and implement retry-on-NOSCRIPT. That path is rarely exercised, therefore rarely tested, and it fires exactly during incidents — after a restart, after `SCRIPT FLUSH`, on a freshly promoted replica whose cache is cold. Libraries are part of the dataset, so they are there after restart and failover. **Shared logic gets an owner and a name.** If three services all EVALSHA the same rate-limiter, each embeds a copy of the source; drift between copies is invisible. One library with a named function makes the contract explicit and lets `FUNCTION LIST WITHCODE` show what is actually installed. **Flags become part of the contract.** Registering with `no-writes` makes a function callable via `FCALL_RO` on replicas and makes it killable if it runs away — a real availability property, not a nicety. **Auditability.** Security review of "what code executes inside our datastore" is answerable by querying the server rather than grepping every client repo. ## Where EVAL should stay - **Ad-hoc and generated scripts** — an admin tool, a migration job, a script whose body depends on runtime input. Installing and later deleting a library for a one-off is worse than sending it. - **Client-private glue** owned entirely by one service with a short lifetime. - **Environments you do not control**: managed Redis offerings and proxies sometimes restrict `FUNCTION` subcommands or predate 7.0; some client libraries and connection pools still lack first-class `FCALL` support or its cluster key routing. Verify before committing the fleet. - **Anything you would otherwise have to rewrite under time pressure.** Migration is optional; EVAL is not deprecated in 7.x. ## What migration does not fix Be explicit about this in an interview, because it is where candidates oversell. Functions run in the same Lua sandbox on the same single command-processing thread. A function that iterates a huge collection blocks the whole server exactly as the script did. Atomicity, no rollback on error, the requirement to declare every key, single-slot restriction in Cluster, and effects-based replication are all unchanged. If your problem is a slow script or an unkillable one, the fix is bounding the work and flagging `no-writes`, not changing the invocation command. ## A migration plan that survives contact with production 1. **Inventory.** Enumerate every script: its source, its call sites, its key pattern, its p99 latency, whether it writes. Some will turn out to be dead, and some will turn out to be better expressed as plain commands or a pipeline. 2. **Group into libraries by ownership.** One library per bounded capability (`ratelimit`, `inventory`), not one library per script. Function names are unique server-wide, so agree a naming convention early. 3. **Port and unit-test.** Callbacks taking `(keys, args)` are testable outside Redis; add tests for the branches the NOSCRIPT-era code never had. 4. **Deploy the library first, call it later.** Load with `FUNCTION LOAD REPLACE` on every primary as an idempotent pipeline step. Loading unused code is harmless. 5. **Cut over per call site behind a flag.** Keep the EVALSHA path alive. For high-risk paths, dual-run in shadow (call the read-only variant and compare) before switching writes. 6. **Watch the right signals.** `FUNCTION STATS` for running functions, `SLOWLOG` and latency percentiles for regressions, error rates for flag mistakes (a `no-writes` function that occasionally writes will error only in the rare branch). 7. **Delete the old path.** Remove the script constants, the SHA caching and the NOSCRIPT retry from the clients. If you leave the fallback in, you have paid the cost and kept the risk. 8. **Version deliberately.** Either in-place `REPLACE` when the contract is unchanged, or side-by-side `orders_v2` with new function names and a traffic flip when it is not — the latter is the only cheap rollback. ## The decision in one sentence Migrate the logic that behaves like a shipped capability of the data tier — long-lived, shared, operationally load-bearing — and leave the scripts that behave like queries.