Phoenix + LiveView

Inspect the source

Inventory schema, constraints, record identifiers and callbacks previously triggered by writes. Ecto schemas and changesets must preserve the intended domain semantics, not simply the old table shapes.

During coexistence

Recommendation: keep the source application as the authoritative writer while Phoenix contexts read fixtures; move a tenant or domain operation with one named writer. Use additive schema changes and a single migration runner during shared-table operation.

Target design

Contexts calling Ecto Repo with explicit validation and transaction boundaries. Ecto.Multi composes related Repo operations in one database transaction; cross-store side effects require a separate delivery design.

Rollback

Recommendation: return the domain writer to the source while preserving additive schema and reconciling accepted new writes; delay destructive contractions until the rollback window closes.

Benefits and prerequisites

Recommendation: a context boundary can expose one reusable domain operation to LiveView, controllers and workers.
Requires: Resource authorization, constraints and side effects moved with that operation.
Tradeoffs: Shared-schema coexistence limits schema changes; external effects do not become part of a database transaction.

Checks before transfer

• Write a fixture through each allowed writer and read it from both runtimes; compare IDs, enum/null values, timestamps and constraint failures.
• Fail the second operation in an Ecto.Multi and verify the first database operation is absent; prove old readers still accept successful new writes.

Inspect the source

Rails workers currently own Ruby job execution, including Active Job/GlobalID serializers and backend retry/scheduling behavior. Record the actual Redis-backed backend and every backlog state rather than inferring it from the word Rails.

During coexistence

Recommendation, retain/wrap path: keep Ruby workers and their broker; expose a narrow producer endpoint or durable outbox relay for Phoenix. Ruby remains the only consumer and scheduler for retained categories, and the interface names payload version, business idempotency key and enqueue acknowledgement.

Target design

Phoenix web/domain code with retained Ruby worker ownership is a valid permanent composition when queue interoperability or Ruby libraries remain necessary.

Rollback

Recommendation: restore the old web producer while retaining the same workers; reconcile accepted interface/outbox entries before disabling the relay.

Benefits and prerequisites

Recommendation: the web layer can transfer before job execution without transforming the old backlog.
Requires: Defined producer interface, monitored delivery and retained worker deployment.
Tradeoffs: Two runtimes and the broker remain operated; domain write plus broker enqueue is not a shared SQL transaction.

Checks before transfer

• Submit a captured serializer/GlobalID case through the interface and confirm the intended Ruby class executes with its normal failure policy.
• Interrupt delivery after domain commit; recover it without duplicating a business effect. Verify only the Ruby scheduler owns the retained category.

Inspect the source

A retained Redis broker may carry Sidekiq/Resque-shaped jobs; framework wrappers, class names, serializer tags and version-sensitive timestamps are still part of the execution contract.

During coexistence

Recommendation, broker-retaining replacement path: qualify Exq for selected job types on isolated queues. Keep unsupported Ruby types on Ruby consumers; map only deliberately supported payload versions, and give each category one consumer family and schedule owner.

Target design

Selected Elixir workers using Exq's documented Redis-backed Resque/Sidekiq-compatible format. This is a candidate for qualification, not a claim that arbitrary Active Job payloads are interoperable.

Rollback

Recommendation: stop new consumption and return only backward-readable queued work to Ruby; preserve both consumers for payloads accepted during the transition.

Benefits and prerequisites

Recommendation: selected job execution can move to Elixir while preserving the broker boundary.
Requires: Fixture-tested serialization, queue isolation, retry mapping and scheduler ownership.
Tradeoffs: Redis remains; compatibility and unsupported Ruby argument types require explicit maintenance.

Checks before transfer

• Replay ordinary arguments, an Active Job wrapper, serializer edge cases and scheduled/retry payloads; reject unsupported cases without consuming them silently.
• Crash after a business effect before acknowledgement and verify replay safety; confirm old and new consumers never race for an unqualified category.

Inspect the source

Legacy Redis jobs and a proposed SQL queue have distinct payload/storage formats and retry/schedule state. A backend change does not copy the backlog or the recurring schedule.

During coexistence

Recommendation, SQL replacement path: run Oban alongside the legacy broker and route selected categories exclusively to one system. Keep old ready, retry, delayed, failed and running work accounted for. Transfer each schedule once; use a recoverable relay/outbox while domain data and queue insertion span stores.

Target design

Oban workers on the chosen supported SQL engine. With the same Repo/transaction, Oban.insert in Ecto.Multi can join domain changes; a separate database cannot gain that atomicity merely from both databases being SQL.

Rollback

Recommendation: pause new producers/consumption, keep accepted Oban payloads executable, and reconcile effects before moving routing back. Do not blindly copy all rows into the old broker.

Benefits and prerequisites

Atomic domain-write-and-job-insert is available within a shared transaction.
Requires: One supported database transaction/Repo for both writes and business idempotency for execution.
Tradeoffs: Queue load shares the database; SQL atomic insertion does not guarantee exactly-once external effects.

Recommendation: broker retirement can reduce the operated service inventory.
Requires: All Redis uses transferred, all backlog states reconciled and recovery/rollback checks passed.
Tradeoffs: Redis plus SQL coexistence temporarily adds operational work; no service reduction occurs while Redis remains needed.

Checks before transfer

• Rollback the combined transaction and confirm neither domain change nor executable Oban job remains.
• Pause a selected Oban queue, reconcile running work and inspect retained backlog; resume without duplicated effects.
• Restart during a job and validate the selected engine's configured recovery policy, including a failure after an external side effect.

Inspect the source

Record old cookie encoding, serializer, keys/salts, expiration and session revocation; shared account IDs alone do not establish cookie compatibility. Plug COOKIE defaults its serializer to external_term_format and exposes rotating cryptographic options.

During coexistence

Recommendation: retain the existing identity authority through a qualified session exchange or compatibility decoder. Map authorization rules into Phoenix contexts and LiveView mount/events; keep account and revocation ownership explicit.

Target design

Phoenix identity with the selected session store and LiveView authorization in mount/on_mount and actions. Recommendation: choose planned reauthentication when cookie compatibility is not worth maintaining.

Rollback

Recommendation: retain the old decoder/exchange until routing can return; never reverse revocation merely to restore traffic.

Benefits and prerequisites

Recommendation: users can preserve access while a connected feature moves.
Requires: Qualified decoder/exchange, shared revocation and event-level authorization.
Tradeoffs: Long-lived sockets need explicit disconnect/recheck behavior when access changes; sharing secrets alone is insufficient.

Checks before transfer

• Login through the old runtime, access the target feature, revoke the account/session and confirm HTTP plus existing/reconnected LiveView access follows the required policy.
• Send a forged delete event for another tenant despite a hidden UI control; confirm the server rejects it.

Inspect the source

Action Cable, Phoenix Channels and LiveView are different protocols. Capture subscription identity, event envelope, authorization, ordering and missed-message recovery. Channels documents at-most-once client delivery without server persistence.

During coexistence

Recommendation: retain old client endpoints and bridge versioned domain events into each renderer. A room/tenant cohort owns its subscriptions and reconnects. Choose Redis PubSub or a qualified distributed-Elixir cluster deliberately; sharing Redis does not translate the wire protocol.

Target design

LiveView for connected server-owned screens or Channels for explicit realtime clients, with durable domain state and an application catch-up mechanism when missed events matter.

Rollback

Recommendation: preserve the old endpoint/event envelope and cohort routing through reconnects; rebuild UI from persisted state instead of duplicating broadcasts.

Benefits and prerequisites

Recommendation: connected UI and domain operations can share Phoenix contexts.
Requires: Authorized subscriptions, working multi-node fanout and persisted state/cursors for recovery requirements.
Tradeoffs: Live protocol/client changes and cluster operations remain; PubSub does not supply a durable user-message history.

Checks before transfer

• Place old/new subscribers on separate nodes; commit through either permitted path and verify every authorized recipient converges once.
• Disconnect before an event, restart a node, reconnect with the chosen cursor/state mechanism and verify missed domain changes recover; test revocation while connected.

Inspect the source

Classify every Redis use as cache, session, limiter, lock, job or PubSub. ETS tables are node-local and their ownership lifetime matters; they do not provide Redis's cross-node boundary.

During coexistence

Recommendation: move only reconstructible cache entries into supervised local ownership, with explicit TTL/invalidation and bounded memory. Keep shared identity, coordination, queues and broadcast infrastructure until their own transitions qualify.

Target design

ETS for deliberately local reconstructed values, or a retained shared cache where consistency across nodes is required. Recommendation: state stale-read tolerance and rebuilding behavior in the application contract.

Rollback

Recommendation: switch those reads back to the qualified shared store or authoritative data; retain Redis until every remaining capability is reconciled.

Benefits and prerequisites

Recommendation: a local cache can remove a remote dependency from selected reads.
Requires: Acceptable node-local semantics, bounded memory and verified invalidation/rebuild behavior.
Tradeoffs: Each node maintains separate contents; owner/node failure loses local state. Performance benefit requires measurement.

Checks before transfer

• Warm two nodes, update the authoritative record and verify their documented staleness/invalidation policy.
• Terminate the table owner or restart the node; verify the application rebuilds and no durable job/session/lock state was stored there.

Inspect the source

Record endpoint, worker, scheduler, Repo, assets and cluster/PubSub ownership. Phoenix runtime configuration, release build and schema migrations have distinct deployment steps.

During coexistence

Recommendation: maintain both releases with stable cohort routing and a single schedule/writer owner per responsibility. Monitor queue age, retry effects, node connectivity and authorization failures against application-specific promotion thresholds.

Target design

A Phoenix release with runtime.exs configuration, built assets, named migration runner and supervised workers. Recommendation: make cluster formation, backups and restore ordering explicit instead of assuming VM startup establishes them.

Rollback

Recommendation: retain the previous release and compatible database reads; return cohort routing and role ownership separately, reconciling new jobs and external effects.

Benefits and prerequisites

Recommendation: explicit supervised roles and release inputs make restart behavior reviewable.
Requires: Configured children, deployment inventory and exercised recovery procedures.
Tradeoffs: Durable recovery still depends on the chosen databases/queues; supervision alone cannot recreate lost external state.

Checks before transfer

• Start the actual release with a disposable restored database and confirm assets, authenticated routes, a queued job and cross-node broadcast work.
• Stop a worker/node, observe detection and recovery, and verify no second schedule owner activates during rollback.