Verify Reporting, Exports and Service Accounts Before Database Cutover

Retain consumer-specific target, role, query, freshness, schedule and delivery evidence before moving downstream database readers.

Before moving downstream readers, verify each consumer's actual database connection, effective identity, business query and delivered data cut. Then test the paths that will run after the change: fresh credentials, restarted workers, scheduled extracts and refreshed caches. A successful target query does not prove that a dashboard is fresh or that an export reached its recipient. Keep a required consumer held while any part of that obligation is failed or unobserved.

This playbook concerns one orders database on two separate Amazon RDS for PostgreSQL DB instances, using PostgreSQL 17 documentation semantics. Exact server/provider releases, Region, client versions and runtime configurations must be collected before execution. A separately owned replication and paired-data procedure supplies the comparison boundary. Aurora, RDS Proxy, managed Blue/Green, read-replica routing, engine conversion, writer admission and schema changes are excluded. All worked identities, times, results and receipts are fictional. No AWS request, SQL statement, scheduled job or delivery was executed.

1. Close the consumer population around business outputs

Migration lead with business owners: produce the consumer register. Start with the outputs people rely on: an inventory dashboard, a finance CSV, a support lookup, a partner extract or a fraud-review query. For each identify its owner, process/job revision, database role, connection configuration, query artifact, derived storage and destination. Record which consumers share a credential without assuming they share initialization, caches or deadlines. One role can serve several materially different obligations.

Reconcile deployment manifests, connection-secret consumers, scheduler definitions, reporting configurations and owner interviews with approved runtime observations. Keep dormant month-end jobs, disabled reports, remote schedulers and manual exports visible. A short session sample cannot prove absence of a quarterly consumer. The owner should state which exceptional runs were inspected and which remain unobserved. If the team knows a job exists but cannot identify its execution path, add a held row rather than reducing the denominator.

Classify mixed readers separately. An export may read business tables but update its own checkpoint or send a message. That makes output/replay ownership part of this task, while database mutation authority belongs in the writer inventory. A consumer advertised as read-only can still call a mutating routine or write outside the database. Declare those paths and involve their owners. Do not hide them by choosing a SELECT-shaped screenshot as the whole consumer.

2. Authorize collection and isolate proposed execution

Security reviewer and environment owners: retain the access and stop plan. Approve specific metadata reads, query revisions, synthetic populations, observation interval, load limits and evidence locations. Collection authority does not permit role changes, token creation, job execution, cache deletion or delivery to a real recipient. Tests require a separate approval for the exact environment and effects. The application owner verifies inert destinations and disabled automatic schedules before a rehearsal begins.

Set a bounded query/connection budget and an operator who can stop the exercise. A report can consume enough CPU or hold a long transaction to disturb the system it is validating. Limit parallel runs and preserve actual errors and incomplete reads. A statement timeout or denied object read is missing evidence, not an empty result. PostgreSQL's read-only transaction rules are a useful restriction, but not a universal isolation guarantee for disk activity or external client effects.

Protect evidence deliberately. Keep actual endpoints, role mappings, query texts and permitted raw outputs in a controlled store. Never put passwords, IAM tokens, connection strings with secrets or personal export rows into the editable register. Its aliases must resolve to retained immutable revisions maintained by the owner. An unchanged alias can conceal an edited artifact; the reviewer must check contents and identity outside this document. Stop if the collection exposes data beyond the approved scope.

3. Bind observations to the real client and target

Consumer owner and target DBA: output a destination receipt. Capture the running process revision, active connection configuration, connection time, driver version and owner-bound resource identity. Tie the session to the intended database and target resource using approved operational evidence. A hostname can be cached; an address can change; a database name can exist on both instances. None is a sufficient independent cloud-resource identity on its own.

PostgreSQL's system-information functions distinguish database, session user, execution user and server address. Use that context to challenge the binding, not to manufacture resource authentication. An operator querying the target from a laptop does not prove that the reporting worker's connection pool uses it. Retain an observation through the actual approved consumer path and pair it with the configuration/resource evidence. If that path cannot be observed, keep its destination unknown.

Retain actual TLS verification settings and trusted CA references for the driver. RDS PostgreSQL SSL guidance distinguishes certificate verification settings and documents client defaults that can prefer SSL. A successful connection or an encrypted-session indication does not establish hostname/certificate verification. Do not downgrade verification to get a test to connect. Correct the connection contract through its owner, then repeat the scoped evidence under a new configuration revision.

4. Exercise identity initialization and reconnection separately

Credential owner and consumer maintainer: retain established-session and fresh-connection records. Record the login identity, execution role, memberships needed by the query and initialization applied by the client. A database administrator's successful query is not the intended service account's result. Where role switching is part of the application, observe its actual sequence. PostgreSQL SET ROLE changes permission checking but does not apply the selected role's login-time settings.

For consumers that use IAM database authentication, verify actual engine/Region availability and token-generation/client handling under the approved design. AWS documents a 15-minute token lifetime that does not end an established session. An existing pool can remain functional while its next connection fails. The required evidence therefore includes an approved fresh-connection path, not a wait for a guessed session expiry. Keep tokens out of logs and the register.

Do not require an artificial token test for password-based consumers. Their credential source, rotation and restart behavior need the corresponding evidence instead. For either method, keep an independently observed connection failure separate from query denial. Test the scheduler or worker restart that actually reloads credentials/configuration. A manually restarted local copy may not represent the deployed controller. An unobserved reconnect leaves that mode held even if the existing connection delivered the expected rows.

5. Test the consumer's permitted query meaning

Business query owner with DBA: output expected and observed results. Freeze query/projection revision, named objects, parameters, timezone, ordering, pagination and intended caller before collecting target results. Include a required positive and a meaningful rejection or boundary case. The source can contain a defect, so define business expectations independently instead of assuming every old answer is correct. Approved intended differences need their own rule revision and owner.

Use the actual role when testing row visibility. PostgreSQL row-security policies can filter returned rows; owners normally bypass those policies and privileged bypass roles behave differently. Two rows returned to a service account and four to an administrator are not automatically a lost-data incident. Conversely, four rows returned to a tenant-scoped account can be a disclosure failure. Compare the expected population for that identity, retaining both missing and unauthorized rows.

Review object resolution and initialization. The schema search path chooses the first matching unqualified object, so equal query text can refer to different objects. Record qualified object definitions or effective resolution evidence without prescribing a global search-path change. Preserve query-specific extension, collation and format dependencies for their separately owned compatibility tests. Stop on an unexpected object, privilege or tenant scope; do not rerun as an administrator and report that as remediation.

6. Establish freshness against a data cut, not a query clock

Data-boundary owner and consumer owner: produce a freshness contract. Define the required committed business cut, how it is mapped to the target, which records must be included and the maximum allowed delivered age. A query timestamp only says when a query ran. PostgreSQL date/time functions distinguish transaction-start time from the actual clock. Neither time proves that the selected business changes were included.

Use the independently accepted paired-cut procedure to establish source/target comparability. PostgreSQL isolation can make successive statements use different snapshots at Read Committed or a stable transaction snapshot at Repeatable Read. That does not synchronize separate instances. If the cut mapping is missing, keep the freshness claim unknown instead of converting a low infrastructure lag metric into application acceptance. Preserve the collection interval and the mapping's exclusions.

The business owner specifies whether freshness means all changes through a cut, a maximum age, a completed reporting period or a combination. Record the reference timestamp and clock uncertainty used for age calculations. A future or incomparable timestamp cannot produce favorable negative age. A permitted ten-minute age does not excuse a missing required cancellation, nor does an old historical report necessarily need current-day data. Choose the rule from the output contract, not a universal minute threshold.

7. Follow materialization and caching to the displayed answer

Reporting owner: retain origin, transformation and delivered-output receipts. List materialized views, extracts, BI datasets, application caches and download artifacts on the consumer's actual path. A base-table comparison can pass while a report reads a separately retained result. PostgreSQL materialized views store query results and may not be current. Do not infer that a replication tool refreshes these results or migrates an external cache; verify the chosen mechanism's coverage separately.

For each derived stage record its input cut, transformation revision, refresh/run identity, completion and delivered cut. If a cache has no reliable provenance or invalidation observation, retain that limitation. A force-refresh button is a request, not evidence that the displayed result changed. Observe the actual screen/API/download path with inert data and the intended identity, including the chosen cache-hit and cache-miss cases. Disable delivery if the test could send unapproved content.

Proposed evidence relationship, not a deployed AWS topology. Solid arrows carry review records. Every required branch must refer to the same consumer revision and obligation. Scoped review-ready is non-authorizing; any failed or unknown required branch keeps the obligation held.

Preserve the failing cached output before requesting a correction. Record which cache, refresh job or transformation changed and which evidence was invalidated. Repeat dependent delivery checks, not only the database query. Avoid silently substituting a direct SQL answer for the visible dashboard the business actually uses.

8. Observe schedules, deadlines and uncertain delivery

Scheduler owner and recipient owner: retain a full job receipt. Record the actual scheduler revision, timezone, exceptional calendars, trigger, job start/end, output identity and completion meaning. Matching schedule configuration does not prove a completed run. Test the approved trigger path, credential reload and permitted retry behavior. Include month-end or daylight-saving behavior when relevant to the real contract; unobserved exceptional schedules remain explicit exclusions, not implied passes from one UTC example.

An extract can finish querying before its deadline while delivery is unknown. Distinguish file creation, atomic publication, recipient acceptance and business ingestion. Preserve stable operation/output identity so a retry cannot silently duplicate a consumed file. If a delivery times out after submission, obtain durable recipient evidence before replaying. A local success exit code cannot resolve an absent acknowledgement, and a local failure does not establish that the recipient received nothing.

Alternatives must preserve the obligation. A temporarily held report can be acceptable if its owner authorizes a visibly stale or unavailable experience for an isolated scope. A manual extract may replace a schedule only with named staffing, controlled credentials and the same freshness/delivery evidence. Retaining the old reader may be possible while its source remains an agreed read authority, but a stale source after target writes is not a safe permanent fallback. Record the actual authority boundary before choosing that option.

9. Work through three contrasting fictional consumers

The fictional orders population has tenant-A rows O1/60 and O2/60 at cut C42, with independently expected total 120. Earlier cut C40 has O1/40 and O2/60, total 100. Tenant-B has two excluded rows totaling 100; an overprivileged answer across both tenants totals 220 at C42. Amounts are unitless teaching values, not prices. C42's stipulated freshness timestamp is 09:55 UTC and C40's is 09:45 UTC. The synthetic delivered-age budget is 600 seconds, inclusive. No timestamp is an executed observation or a mapping from a PostgreSQL/DMS position.

Dashboard D1, revision dashboard-r4. Its supplied target query returns the expected tenant-A total 120 at C42. Its delivered cached report at 10:05 still refers to C40 and total 100. Age is 20 minutes, or 1,200 seconds, over the 600-second budget. The required cut and expected output also fail. Hold the dashboard; a favorable base query cannot clear it. The reporting owner must retain the stale output, verify refresh/cache provenance and repeat the actual display path.

CSV export E1, revision export-r8. Its supplied target query and file both represent C42 and total 120, with file completion at 10:03. That age is eight minutes, or 480 seconds, within the stipulated budget. Its inert-recipient acknowledgement is missing. The scheduler's local exit code is supplied as success, but the obligation is held for uncertain delivery. Do not rerun automatically. The recipient owner must establish whether output E1-C42 was accepted and assign the replay disposition.

Service lookup S1, revision lookup-r12. Supplied established/fresh-connection and caller records refer to the intended target and tenant-A role. Its C42 response at 10:04 contains O1/60 and O2/60 only, total 120; age is nine minutes, or 540 seconds. The supplied other-tenant test returns no unauthorized rows, and its synchronous response receipt is present. It has no schedule/cache by the fictional contract. This record is scoped evidence-complete on paper, not an observed migration pass. Real resource evidence and separately authorized execution remain absent.

The register therefore has one stipulated complete record and two held obligations. It is not “one third migrated,” because no runtime was observed and obligations may depend on each other. A useful opposing case changes D1's delivered cut to C42 and timestamp to 10:05: age becomes exactly 600 seconds and meets this inclusive budget, but only current query, identity, refresh and delivery evidence can make its scoped record complete. A second case changes S1's caller to a bypass identity returning 220: freshness still looks favorable, while tenant semantics fail. These cases force the reviewer to keep independent requirements separate.

10. Complete the reusable consumer record

Download the anonymous consumer-evidence companion for the editable record and fictional consumer register. They contain no credentials or running endpoints. The companion does not discover consumers, authenticate evidence, execute queries or evaluate migration admission. Keep one row per materially distinct process/revision/output path. Complete each field with retained evidence or an explicit unknown; do not copy the fictional results into a live decision.

Filled example: successful query, uncertain export

Consumer, revision and owner

E1 / export-r8; fictional export-owner; output E1-C42

Obligation and population

Tenant-A CSV with O1/60 and O2/60, total 120; two tenant-B rows excluded

Environment and target binding

pg-source-A to pg-target-B; actual resources, builds, Region and driver UNKNOWN

Caller and connection modes

export-role-A intended; established/reconnect receipts stipulated, not authenticated

Query and session context

query-export-r3; tenant filter, object resolution, role, UTC and policy checks required

Cut and freshness rule

C42 required, timestamp 09:55 UTC; maximum delivered age 600 seconds inclusive

Derived stages and delivered data

No cache by stipulated contract; file E1-C42 carries C42 and total 120

Schedule and completion

schedule-r2; file completed 10:03 UTC, age 480 seconds; actual trigger not executed

Recipient and effect isolation

inert-recipient-A; acknowledgement MISSING; no real delivery occurred

Expected results and failure cases

Correct C42/120; stale C40/100 and wrong-tenant 220 reject; timeout requires settlement

Disposition and recovery

HOLD uncertain delivery; recipient owner resolves E1-C42 before any replay

Invalidators and next evidence

Changed client, role, query, cut, schedule, destination or receipt reopens review; obtain actual acknowledgement

Blank record: complete the same evidence boundaries

Consumer, revision and owner

Process/job ID, immutable revision, accountable owner and output operation identity

Obligation and population

Business output, permitted tenants/keys, required period, projection and exclusions

Environment and target binding

Exact resources/database/provider/server/client versions, Region, active configuration and runtime receipt

Caller and connection modes

Login/execution roles, credential source, established/fresh/restarted paths and unavailable evidence

Query and session context

Query/object revisions, initialization, effective settings, policy population and negative case

Cut and freshness rule

Required cut and independently accepted mapping; clocks/uncertainty; age/deadline rule and missing fields

Derived stages and delivered data

View/cache/extract lineage, input/output cuts, refresh/run identities and actual delivered result

Schedule and completion

Scheduler revision/timezone/calendar, trigger, start/end, retries and exceptional-run coverage

Recipient and effect isolation

Inert rehearsal destination; actual output identity/acknowledgement; uncertain-effect owner

Expected results and failure cases

Independent positive/negative expectations; actual differences, incomplete reads and residual scope

Disposition and recovery

Failed, HOLD or bounded evidence-complete; stop/replay rules and separate authority

Invalidators and next evidence

Changed dependencies, evidence revisions, reviewer/date and next specific owned observation

11. Stop, recover and repeat without concealing outcomes

Consumer owner with incident/cutover lead: retain the failed basis and recovery decision. Stop on wrong target, unintended privilege, exposed tenant data, unexpected external effect, missing cut mapping or an exceeded observation/load budget. End only the approved test session/job through its safe stop path. Preserve partial results, file identities, client errors and pending acknowledgements. Do not erase caches or replace failing output before the observer retains it.

A wrong query needs its query/object/context correction; a stale display needs its materialization/cache correction; an uncertain delivery needs settlement. Route reversal alone solves none of those reliably. Before target writes, a source-reader return may be possible within the separately rehearsed migration boundary. After target writes, the old source can be stale. Use the actual migration recovery plan rather than assuming a DNS change restores current reports. Never reactivate both old and new delivery schedules without explicit ownership of duplicate effects.

Repeat under a new packet revision after the approved correction. Include the same failing case plus dependent checks and invalidate earlier receipts affected by the change. One fixed cache answer does not accept a weekly export or another role. A smaller scope can advance only if its independence from held consumers is demonstrated and its business owner accepts the limitation. Keep refused, unknown and failed outcomes in the register so a later reviewer can reconstruct why the change occurred.

12. Acceptance checklist and next owned action

Done means the accountable consumer owner and independent observer have retained current evidence for every required runtime, permitted population, committed cut, derived output, connection mode, schedule and recipient boundary, including dormant and exceptional consumers. Required failures or unknowns hold the dependent obligation with an owner and next evidence. Exclusions need the business owner's explicit scope decision. Changed dependencies or receipt revisions reopen affected checks. This bounded record does not authorize cutover, execution or replay.

The migration lead and independent observer check that the denominator includes required dormant and exceptional consumers; every output has an accountable owner; real client/target/role evidence is current; the query's expected permitted population is independently defined; and data-cut mapping, derived lineage, schedule/reconnect and destination acknowledgement are complete for every required path. Evidence gathered through a privileged substitute or an unobserved path cannot fill a missing consumer receipt.

Require explicit checks for wrong destination, unauthorized rows, stale materialization, missing reconnect, late/unknown output and uncertain retry effects. Preserve complete coverage and justified exclusions. Any required failed or unknown item holds that obligation. An agreed unavailable or historical output needs its business owner's scope decision, not a green infrastructure dashboard. Evidence-complete describes the retained bounded packet, never universal database compatibility or permission to cut over.

The next useful action is for the migration lead to select the highest-consequence held output and ask its consumer, credential and recipient owners to complete the missing record before scheduling traffic changes. Start with the actual path, not a direct administrative query. Use paired reconciliation for a missing data boundary and migration recovery decisions for a changed authority boundary. An optional AWS migration review can examine the packet; this playbook itself authorizes no access, spend, job execution or migration.