Map the dependencies first
List the tables, collections, and fields that will change, then identify the prompts, saved queries, workflows, and application code that refer to them. A field rename can break a filter even when the underlying records remain intact. A type change can also alter sorting, comparisons, or how a missing value is interpreted.
Decide how existing records will fit the new structure. If old and new formats must coexist temporarily, describe how each is recognized and avoid ambiguous values. For a broad change, choose a representative sample and outline the expected result before modifying the full dataset.
Update and validate consumers
Revise queries and instructions that mention the old field names or assumptions. Test reads against records that cover ordinary and edge cases, then inspect a sample output for missing or misclassified values. If the change includes writes, review their filters and target carefully before applying them.
Keep a note of the prior structure and the reason for the change so collaborators can understand later results. When a workflow or application cannot be updated at the same time, plan a transition period or postpone the schema change. A deliberate migration is easier to diagnose than several disconnected fixes after consumers begin failing.