# Data move of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default to stackit_valkey_instance.dependencies_checkout_elasticache_redis_default Generated by StackToIT. StackToIT moves no data and opens no connection: this is the preparation, run by a person. The document is written from the steps and the checks of the execution plan (execution-plan.json): each section is one step, in the order of the plan, and every sentence, command and check in it is that step's own, so the document holds nothing the plan does not. A command is a template: a placeholder in angle brackets stands for a name, an endpoint or a credential the plan does not hold, and a password is read from the environment, never pasted. StackToIT runs none of them. Source: `module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default` (aws_elasticache_replication_group). Target: `stackit_valkey_instance.dependencies_checkout_elasticache_redis_default`. ## Steps | # | Step | Method | Owner | |---|---|---|---| | 1 | **Method decision.** The methods `client-import` (branch A) and `own-tool` (branch B) are both defined below and none is chosen here: the decision `DEC-GEN-CONVERT-DATA-MOVEMENT` of the plan chooses | every method | not stated | | 2 | Preflight | every method | Data Architect | | 3 | Rehearsal | every method | Data Architect | | 4 | Write freeze | client-import | Migration Owner | | 5 | Final sync | client-import | Data Architect | | 6 | Reconcile | client-import | Data Architect | | 7 | Clean-up | client-import | Data Architect | | 8 | Write freeze | own-tool | Migration Owner | | 9 | Final sync | own-tool | Data Architect | | 10 | Reconcile | own-tool | Data Architect | ## Preflight **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/preflight` (data preflight, phase DATA); owner: Data Architect. **What.** Close what the plan lists as UNKNOWN, from the move host, with read-only commands; no password goes on a command line or into the history of the shell. Source (`valkey-cli -h -p --tls`, without --tls where the source has none): `INFO server` (the engine and its version), `INFO keyspace` and `DBSIZE` (the keys and the keys with an expiry; on every primary when cluster mode is on, listed with `CLUSTER NODES`), `INFO memory` (used_memory and maxmemory), `SCAN 0 COUNT 100` with `TYPE`, `DUMP` and `PTTL` of a few keys of each family (the commands of the copy; the types the copy has no branch for show here), and the credential the copy signs in with. Target (after the draft is applied and the instance and a service key exist; `valkey-cli -u rediss://@: --tls --sni `): `INFO server` (Valkey 8), `DBSIZE` (0) and `INFO memory`; do not expect `CONFIG`, `ACL` or `MODULE`, which a probe found denied to the service key. Check that the move host is in `parameters.sgw_acl` of the instance (remove it afterwards), reaches both ends, and that the clients of the cache are listed with the TLS and the credential each uses. **Why.** the checks of the plan that are UNKNOWN are closed by these commands before any key moves **Needs.** the checks that are UNKNOWN and what closes each: target-memory (closed by: preflight on the source: INFO memory (used_memory, maxmemory) on every primary and the customer's statement of source.dataset.size; the plan_name the customer chooses must offer more RAM per node than the dataset needs, with the headroom the engine's own overhead and the replication buffers take); source-commands (closed by: preflight on the source: run SCAN 0 COUNT 10, DUMP and PTTL of one key and DBSIZE with the credential the copy uses; on the target RESTORE of that key with a TTL, then DEL); source-access (closed by: preflight from the move host: valkey-cli to the source endpoint (with --tls where the source has TLS) and PING, then INFO server); credentials (closed by: the application owners state which user and which commands each client needs; the credential stackit_valkey_credential.dependencies_checkout_elasticache_redis_default is written by the draft, its password is read from the sensitive output after the apply and handed to the clients by the way the customer's secrets are managed); state-or-rebuildable (closed by: the owner of the applications that use the cache states, for each key family, whether it can be lost; a cache that can start empty needs no copy and the decision of the move is answered with the customer's own tool); target-access (closed by: preflight from the move host after the instance exists: valkey-cli --tls to the target with a service key: INFO server, DBSIZE (0), INFO memory (maxmemory), and the move host's address in the access list for the time of the move) **Done when.** every UNKNOWN check of the plan is HOLDS or FAILS; the engine version, the number of keys and their memory, the types of the keys and the shards of the source are known, and the clients of the cache are listed **Risks.** - the move host in the access list is a hole until it is removed at cleanup - a password typed on a command line stays in the history of the shell - check client-tls FAILS: the source states transit_encryption_enabled = false: its clients connect without TLS, and the Key Value Store closes a plaintext connection (a test on 2026-09-24) and accepts TLS only, so every client switches to TLS (rediss://, the driver's TLS option, the instance's certificate authority) before the cutover; the switch is a change of the applications, which this plan cannot make **Rollback.** nothing changed on either side: read-only commands and, on the target, an empty instance ## Rehearsal **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/rehearsal` (data rehearsal, phase DATA); owner: Data Architect. **What.** Rehearse the copy on a sample into a scratch Key Value Store instance of the same plan and version as the draft's instance (a second instance, deleted afterwards: the real instance must stay empty for the final copy): copy the keys of a prefix or a few thousand keys of every family with the client of the copy (`SCAN` with `MATCH`, `DUMP`, `PTTL`, `RESTORE` with the remaining time to live), note the keys a second, the bytes a second and the keys RESTORE refuses, point one copy of the application at the scratch instance with TLS and run its own test suite, and compute the freeze window from the throughput: keys / (keys a second) is the lower bound of the copy. Delete the scratch instance afterwards. **Why.** the transfer lower bound leaves out the round trip of every key and the throughput into a Key Value Store is not verified; only a rehearsal measures them and shows which keys the target refuses **Needs.** the customer's statements in inputs.yaml: source.dataset.size, source.dataset.bandwidth **Done when.** the keys a second and the refused keys are recorded, the application's tests pass against the scratch instance over TLS, and the write-freeze window is agreed from them **Risks.** - a scratch instance is billed while it exists **Rollback.** delete the scratch instance; the draft's instance and the source are untouched ## Write freeze (client-import) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/write-freeze/client-import` (data write freeze, phase CUTOVER); owner: Migration Owner. **What.** Freeze the writers of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default: list who writes, record the connection settings of every client, then stop the services, jobs and migrations that write; do not change the source **Why.** the last copy and the comparison of the two sides are made with the writers stopped, and the source stays untouched so the way back needs nothing on the source **Done when.** no client writes to the source **Method.** This step belongs to the method `export-and-import-with-the-engine-clients` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** start the writers again against the source: nothing was changed ## Final sync (client-import) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/final-sync/client-import` (data final sync, phase CUTOVER); owner: Data Architect. **What.** Inside the freeze, copy every key of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default to stackit_valkey_instance.dependencies_checkout_elasticache_redis_default with a client that you run, not with the `MIGRATE` command: iterate the keys of the source with `SCAN` (never `KEYS`), read each key with `DUMP` and its remaining time to live with `PTTL`, and write it into stackit_valkey_instance.dependencies_checkout_elasticache_redis_default with `RESTORE` (the TTL in milliseconds, 0 for a key that has none, and without `REPLACE`), after you isolated the source (no application connected to it) and took a backup of it. The source shows one shard (it states num_cache_clusters, which the provider documents as conflicting with num_node_groups): the copy iterates one node, the primary **Why.** the draft creates the instance empty; the tutorial "Migrate data to a new instance" of the service migrates a STACKIT Redis instance by the MIGRATE command or by a script, and the plan holds a copy by a client that rests on commands the source's service lists as supported (below); the plan does not know the number of keys, their names or types, or the network between the source and the target **Needs.** the number of keys, the network path from the host that runs the client to the source and to the target, and the downtime the business accepts; Precondition, checked by a person before the copy (the plan reads no network of the source and the target, so reachability is not claimed): the host that runs the client must reach the source and the host and port of stackit_valkey_instance.dependencies_checkout_elasticache_redis_default that its service key states (the tutorial says to use the exact host of the credentials for the source and the target; it names the backend host only for MIGRATE, whose connection is made by the source, and states nothing more for a client, so confirm the target host with a first connection); the access list the draft writes for stackit_valkey_instance.dependencies_checkout_elasticache_redis_default (parameters.sgw_acl, from var.dependencies_checkout_elasticache_redis_default_allowed_cidrs, which has no default) must admit the address the client connects from, and the tutorial does not say how that list applies to the backend route, so confirm it with a first connection from that address; and stackit_valkey_instance.dependencies_checkout_elasticache_redis_default must be empty (the tutorial: "Do not insert any data into the target instance until the migration and consistency checks are fully completed") **Done when.** every key of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default is in stackit_valkey_instance.dependencies_checkout_elasticache_redis_default: the client reported no error and the comparison of the two key spaces ends in GO **Risks.** - the tutorial's main strategy is the MIGRATE command with its COPY option, piped from a KEYS '*' listing; the plan does not use it because it holds no statement that the source allows MIGRATE (for Amazon ElastiCache the page below says it does not), and the tutorial's listing with KEYS is not used either - DUMP returns a serialized value that holds an RDB version and a checksum and no expire time (valkey.io/commands/dump), RESTORE fails when the version or the checksum does not match (valkey.io/commands/restore), and PTTL answers -1 for a key without expire and -2 for a key that is gone (valkey.io/commands/pttl): the client restores a key without expire with a TTL of 0, skips a key that is gone and counts it, and reports a key that RESTORE refuses; try the first keys before the whole copy - RESTORE without REPLACE refuses a key that already exists ("Target key name is busy", valkey.io/commands/restore): that is what shows a second attempt on a target that still holds keys, so remove them first (the way back below); SCAN may return a key more than once (valkey.io/commands/scan), and the second RESTORE of such a key is not an error of the copy - the plan has not run this copy against a Key Value Store: that the service accepts RESTORE is inferred from the tutorial's MIGRATE ... COPY, which ends in a RESTORE on the target (valkey.io/commands/migrate), not from a statement of the service - the tutorial recommends a manual backup of the source before the migration, kept until the consistency of the target is confirmed - the source does not say whether this cache holds only what the application rebuilds or also data that exists nowhere else (sessions, locks, counters, queues), so the plan keeps the copy rather than assuming the cache can start empty - the tutorial's source is a STACKIT Redis instance (its TLS, backend-host and key-listing steps are those of STACKIT); an Amazon ElastiCache or MemoryDB source of the same steps is an inference, not a statement of the page - the Amazon ElastiCache page lists migrate among the commands it does not make available for caches running Redis OSS (with sync, psync, replicaof, bgsave, save and config) and does not state that restriction for Valkey caches; the plan takes MIGRATE as available for no ElastiCache engine and copies the keys with a client on every one; the same page lists DUMP, RESTORE, SCAN, PTTL, INFO and DBSIZE among the commands serverless caches support, and its lists of restricted commands name none of them - the script copy_redis.py of the tutorial (the plan has read it: it lists the keys with SCAN, reads each key by its type and writes it with SET, RPUSH, SADD, HSET or ZADD, and sets the TTL in whole seconds) does not use KEYS, but it has a branch only for strings, lists, sets, hashes and sorted sets, so it copies nothing for a key of another type (a stream, for one), it decodes every key name as UTF-8, and it opens one connection to one source host; count the keys of each type on the source before you choose it over the client above **Method.** This step belongs to the method `export-and-import-with-the-engine-clients` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** the writers are stopped, not removed, and the copy only reads the source with SCAN, DUMP and PTTL, so the source cache is the way back until the reconcile records GO: put the writers back on it; before another attempt remove the keys the client wrote into stackit_valkey_instance.dependencies_checkout_elasticache_redis_default (the draft created it empty) ## Reconcile (client-import) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/reconcile/client-import` (data reconcile, phase CUTOVER); owner: Data Architect. **What.** Reconcile module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default and stackit_valkey_instance.dependencies_checkout_elasticache_redis_default with the writers stopped (`DBSIZE` and `INFO KEYSPACE` on both sides: the number of keys and the keys and expires values must be equal, where the cache returns the section; the sorted lists of the keys of both, each listed with `SCAN` and never `KEYS`: their difference must be empty; and one read the application does) and record GO or NO-GO **Why.** the comparison of the two sides with the writers stopped is the check of the tutorial of the service (INFO KEYSPACE and the lists of the keys, which the plan makes with SCAN where the tutorial uses KEYS) and does not depend on the way the keys were copied **Done when.** the records and the sample match on both sides, the read the application does returns the same on both, and the owner records GO **Method.** This step belongs to the method `export-and-import-with-the-engine-clients` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** NO-GO: start the writers again against the untouched source; the target holds only a copy ### Verification: the checks after the transfer These are the checks the owner makes with the writers stopped before recording GO; the reconcile step in the execution plan states the same checks, with the same ids. A check with no command says why: the plan states no command it cannot back. - **Count on both sides** (`key-counts`, command): Count the keys and the keys with an expiry on both sides, with the writers stopped (on every primary of the source when it runs in cluster mode). Expected: the number of keys and the expires value are equal on both sides. ~~~text valkey-cli -h -p --tls DBSIZE valkey-cli -h -p --tls INFO keyspace valkey-cli -u rediss://@: --tls --sni DBSIZE valkey-cli -u rediss://@: --tls --sni INFO keyspace ~~~ - **Content on both sides** (`key-lists`, command): List the names of the keys of both sides with SCAN (never KEYS), sort each list and compare them; this proves the same keys exist and not that their values are equal. Expected: the difference of the two lists is empty. ~~~text valkey-cli -h -p --tls --scan | sort > source-keys.txt valkey-cli -u rediss://@: --tls --sni --scan | sort > target-keys.txt diff source-keys.txt target-keys.txt ~~~ - **Application check** (`application-check`, manual): Run one read the application itself makes on its most important data against the Key Value Store and compare its answer with the answer the application gets from the source cache; then, from a test copy of the application, make one write against the Key Value Store and read it back. Expected: the two answers are equal, the write succeeds and the read returns it. - No command: the read and the write are the application's, and the source states neither the query nor the answer. - Not provided, so left as a placeholder or for the owner to fill in: the read the application makes on its most important data and its expected answer; the write the test copy of the application makes. - **Rollback limit** (`rollback-limit`, manual): Record the point after which a rollback loses data. Until the first of the writes that the Key Value Store accepts after the switch, a rollback is only the connection settings put back: the source cache was not changed after the freeze and is current to it. From that write on, what the Key Value Store holds exists only there: it is copied back to the source cache with a method rehearsed before the window, or accepted as lost. Once the source cache is retired (its retirement step, after the GO and the retention the owner decides) there is nothing to go back to. Expected: before the window the owner records the date until which the source cache is kept, the method that copies the writes of the Key Value Store back or the decision that they are lost, and who calls the rollback. - No command: how long the source is kept and whether the writes made on the target are copied back or lost are decisions of the owner of the application: the source states neither, so the plan names the limit and no date. - Not provided, so left as a placeholder or for the owner to fill in: the date until which the source cache is kept; the method that copies the writes of the Key Value Store back, or the decision that they are lost. ## Clean-up (client-import) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/cleanup/client-import` (data cleanup, phase DECOMMISSION); owner: Data Architect. **What.** Only after the target has run in production for the period the customer decides and the way back is no longer wanted: remove the move host from `parameters.sgw_acl` of the instance; delete the files the copy wrote and the snapshot of the source that was taken as the fail-safe once the target is confirmed; delete the scratch instance of the rehearsal if it still exists; and replace the credential of the service key if it was ever on a ticket or in a file. The source cache is deleted only when its owner decides, after a final snapshot kept for the retention the customer decides. **Why.** the move leaves an access-list entry, copies of the data and possibly a scratch instance behind; none of them stays **When.** after the owner records GO at the end of the verification, and once the way back is no longer wanted **Done when.** no copy of the data is left, the move host is out of the access list, the scratch instance is deleted and the credentials are replaced where they were exposed **Risks.** - the source cache is not deleted in the same hour as the cutover **Method.** This step belongs to the method `export-and-import-with-the-engine-clients` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** after the cleanup the way back is the final snapshot of the source cache; there is no other ## Write freeze (own-tool) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/write-freeze/own-tool` (data write freeze, phase CUTOVER); owner: Migration Owner. **What.** Freeze the writers of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default: list who writes, record the connection settings of every client, then stop the services, jobs and migrations that write; do not change the source **Why.** the last copy and the comparison of the two sides are made with the writers stopped, and the source stays untouched so the way back needs nothing on the source **Done when.** no client writes to the source **Method.** This step belongs to the method `migrate-with-a-tool-of-my-own` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** start the writers again against the source: nothing was changed ## Final sync (own-tool) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/final-sync/own-tool` (data final sync, phase CUTOVER); owner: Data Architect. **What.** Copy the data of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default to stackit_valkey_instance.dependencies_checkout_elasticache_redis_default with the migration tool or the replication you chose: write its steps, the checks before the move, the freeze window it needs and the way back **Why.** the draft creates the instance empty and the plan knows nothing of a tool of your own, so it holds the step and the person who chose the tool writes the steps **Needs.** the tool, its steps, the checks before the move, the freeze window and the way back, from the person who runs it **Done when.** the data of module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default is in stackit_valkey_instance.dependencies_checkout_elasticache_redis_default and the checks of the tool hold **Method.** This step belongs to the method `migrate-with-a-tool-of-my-own` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** the writers are stopped, not removed, and nothing the plan does changes the source cache, so the source cache is the way back until the reconcile records GO: put the writers back on it; before another attempt remove the keys the tool wrote into stackit_valkey_instance.dependencies_checkout_elasticache_redis_default (the draft created it empty); check that the tool you chose does not change the source cache, since the plan knows nothing of it ## Reconcile (own-tool) **Step** `MAN/data/module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default/reconcile/own-tool` (data reconcile, phase CUTOVER); owner: Data Architect. **What.** Reconcile module.dependencies.module.checkout_elasticache_redis.aws_elasticache_replication_group.default and stackit_valkey_instance.dependencies_checkout_elasticache_redis_default with the writers stopped (`DBSIZE` and `INFO KEYSPACE` on both sides: the number of keys and the keys and expires values must be equal, where the cache returns the section; the sorted lists of the keys of both, each listed with `SCAN` and never `KEYS`: their difference must be empty; and one read the application does) and record GO or NO-GO **Why.** the comparison of the two sides with the writers stopped is the check of the tutorial of the service (INFO KEYSPACE and the lists of the keys, which the plan makes with SCAN where the tutorial uses KEYS) and does not depend on the way the keys were copied **Done when.** the records and the sample match on both sides, the read the application does returns the same on both, and the owner records GO **Method.** This step belongs to the method `migrate-with-a-tool-of-my-own` of the decision `DEC-GEN-CONVERT-DATA-MOVEMENT`: the plan carries it out only when that decision is answered with it; until it is answered, the steps of every open method are listed. **Rollback.** NO-GO: start the writers again against the untouched source; the target holds only a copy ### Verification: the checks after the transfer These are the checks the owner makes with the writers stopped before recording GO; the reconcile step in the execution plan states the same checks, with the same ids. A check with no command says why: the plan states no command it cannot back. - **Count on both sides** (`key-counts`, command): Count the keys and the keys with an expiry on both sides, with the writers stopped (on every primary of the source when it runs in cluster mode). Expected: the number of keys and the expires value are equal on both sides. ~~~text valkey-cli -h -p --tls DBSIZE valkey-cli -h -p --tls INFO keyspace valkey-cli -u rediss://@: --tls --sni DBSIZE valkey-cli -u rediss://@: --tls --sni INFO keyspace ~~~ - **Content on both sides** (`key-lists`, command): List the names of the keys of both sides with SCAN (never KEYS), sort each list and compare them; this proves the same keys exist and not that their values are equal. Expected: the difference of the two lists is empty. ~~~text valkey-cli -h -p --tls --scan | sort > source-keys.txt valkey-cli -u rediss://@: --tls --sni --scan | sort > target-keys.txt diff source-keys.txt target-keys.txt ~~~ - **Application check** (`application-check`, manual): Run one read the application itself makes on its most important data against the Key Value Store and compare its answer with the answer the application gets from the source cache; then, from a test copy of the application, make one write against the Key Value Store and read it back. Expected: the two answers are equal, the write succeeds and the read returns it. - No command: the read and the write are the application's, and the source states neither the query nor the answer. - Not provided, so left as a placeholder or for the owner to fill in: the read the application makes on its most important data and its expected answer; the write the test copy of the application makes. - **Rollback limit** (`rollback-limit`, manual): Record the point after which a rollback loses data. Until the first of the writes that the Key Value Store accepts after the switch, a rollback is only the connection settings put back: the source cache was not changed after the freeze and is current to it. From that write on, what the Key Value Store holds exists only there: it is copied back to the source cache with a method rehearsed before the window, or accepted as lost. Once the source cache is retired (its retirement step, after the GO and the retention the owner decides) there is nothing to go back to. Expected: before the window the owner records the date until which the source cache is kept, the method that copies the writes of the Key Value Store back or the decision that they are lost, and who calls the rollback. - No command: how long the source is kept and whether the writes made on the target are copied back or lost are decisions of the owner of the application: the source states neither, so the plan names the limit and no date. - Not provided, so left as a placeholder or for the owner to fill in: the date until which the source cache is kept; the method that copies the writes of the Key Value Store back, or the decision that they are lost.