Migration Guide

Move Redis-compatible workloads to Arctickey by changing the connection target, validating TLS, and testing operational behavior before cutover.

Arctickey is designed for EU-hosted app workloads such as caches, sessions, queues, rate limits, locks, and derived data. Keep your primary database as the system of record for durable customer data.

Before You Start#

Create an Arctickey instance in an EU region and collect:

  • Host, port, password, and rediss:// connection string from the Connect tab.
  • Expected TTLs for cache, session, queue, cart, and token keys.
  • A list of libraries that connect to Redis or Valkey.
  • A rollback plan that points the app back to the previous provider.

Use separate test keys first. Do not cut over production traffic until the application can read, write, expire, and reconnect successfully.

Compatibility Checks#

Most standard Redis commands work without code changes. Review these areas before migration:

AreaWhat to check
TLSUse rediss:// and enable TLS in clients. Self-signed local certificates may require disabled certificate verification in development.
PersistenceTreat Arctickey as fast infrastructure, not a primary database for legal records.
TTLsConfirm expiring keys still use EX, PX, EXPIRE, or framework TTL settings.
QueuesPause workers during final cutover if queue payloads are business-critical.
SessionsKeep session signing/encryption keys unchanged when switching Redis backends.
Key prefixesPreserve or intentionally change prefixes to avoid mixing old and new data.
MonitoringRecreate alerts for memory, connections, backups, restores, and repeated health failures.

From Upstash#

Upstash deployments often use either HTTP APIs or Redis-compatible URLs.

If You Use A Redis URL#

Replace the URL with the Arctickey rediss:// URL and verify the client TLS settings:

Terminal
REDIS_URL=rediss://:PASSWORD@INSTANCE.eu.arctickey.com:6379

Then test:

Terminal
redis-cli -u "$REDIS_URL" --tls --insecure PING

If You Use Upstash HTTP APIs#

Arctickey uses the Redis/Valkey protocol, not an HTTP Redis API. Replace HTTP-specific SDK calls with a Redis client such as redis, ioredis, redis-py, go-redis, or Laravel Redis.

Typical changes:

  • Replace UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN with REDIS_URL.
  • Replace REST client imports with a Redis protocol client.
  • Re-test rate limit and cache helper code because HTTP-specific pipeline behavior can differ.

From Redis Cloud#

Redis Cloud migrations are usually connection-string based.

  1. Create an Arctickey instance in the target EU region.
  2. Export or warm critical cache data only if it cannot be regenerated.
  3. Change app secrets from the Redis Cloud endpoint to the Arctickey rediss:// URL.
  4. Recreate IP allowlists, alerts, backup expectations, and runbooks in Arctickey.
  5. Run a canary deployment before switching all app servers.

Check any Redis Cloud-specific features before moving:

  • Modules or search features that are not standard Redis/Valkey commands.
  • Cluster-specific routing.
  • Provider-specific metrics names.
  • Backup retention and restore workflow differences.

From Self-hosted Redis Or Valkey#

For self-hosted deployments, migration is partly technical and partly operational.

Connection Cutover#

Point applications at Arctickey:

Terminal
REDIS_URL=rediss://:PASSWORD@INSTANCE.eu.arctickey.com:6379

If your app currently uses host/port variables:

Terminal
REDIS_HOST=INSTANCE.eu.arctickey.com REDIS_PORT=6379 REDIS_PASSWORD=PASSWORD REDIS_TLS=true

Data Movement#

For caches and short-lived sessions, the safest path is often to let data repopulate naturally.

For queues or important transient state:

  • Stop producers.
  • Drain or pause workers.
  • Export/import only the keyspaces you understand.
  • Start workers against Arctickey.
  • Resume producers.

Avoid copying stale cache keys with long TTLs unless you know they are still valid.

Workload Playbooks#

Cache#

  • Cut over during low traffic.
  • Flush or change key prefix if stale data risk is high.
  • Verify hit rate and latency after deploy.

Sessions#

  • Keep cookie signing keys unchanged.
  • Preserve TTL settings.
  • Consider a short dual-login window if forced logout would be disruptive.

Queues#

  • Pause producers before final cutover.
  • Drain old workers or let them finish current jobs.
  • Start new workers with the Arctickey connection string.
  • Watch retry and failed-job counts.

Rate Limiting#

  • Decide whether limits should reset during migration.
  • If not, migrate only the relevant rate-limit keys.
  • Verify expiry behavior for sliding-window or token-bucket implementations.

Cutover Checklist#

  • Arctickey instance is running in the expected EU region.
  • Application secrets use the Arctickey rediss:// URL.
  • TLS is enabled in every client.
  • Health check can PING, SET, GET, and expire a test key.
  • Queue workers and schedulers have been restarted.
  • Alerts and backup expectations are configured.
  • Rollback secret values are available.
  • Old provider is kept read-only or idle until the cutover is stable.

Rollback#

Rollback should be a connection-string change, not an emergency code deploy.

Keep the old provider available until you have observed normal traffic, memory, queue depth, and error rates through at least one peak period.