A replacement scheduling system can pass its demo and still leave staff with two different answers on Monday morning. Imagine a volunteer declining an assignment in the old tool while someone edits the same service in the new one. Both screens work. The organization now has a reconciliation problem.
Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked sources. The scheduling scenario and rehearsal plan below are illustrative recommendations, not accounts of a production incident or completed migration.
AI makes it easier to explore a replacement: generate a screen, map a schema, try a different workflow. That speed is useful. It also makes it tempting to treat a convincing implementation as the finish line. A replacement has another job: carrying the organization through the period when old and new systems coexist.
My public Garden case study describes a connected platform for people, giving, check-in, serving, communications, and staff work. Its Planning Center replacement is staged, with migration ongoing. The documented validation includes 10,005 synthetic directory records and browser checks; the number is test volume, not congregation size. Remaining migration work, integration gates, and staff acceptance still matter.
That distinction changes how to plan a release. A synthetic directory can establish that pagination behaves as expected. It cannot establish that a staff member knows where to record a change during the transition, or that an imported relationship means what the organization expects.
For an AI-assisted rewrite, I would make the transition itself a testable feature. Give it a named owner, a bounded workflow, and a rehearsal that includes an interruption. “People records moved” is too broad an acceptance statement. “Staff can find the correct household, make an authorized correction, and explain which system owns the next change” is something a team can investigate. This is a current engineering concern beyond small custom applications. In its October 5, 2026 Google Cloud Modernize announcement, Google brought agentic assessment and application modernization into a broader transformation portfolio. That announcement is an ongoing trend, rather than a new release this week.
The same announcement includes Dual Run for comparing legacy and modernized workloads. Google's Dual Run documentation describes comparing outputs from the same inputs and replaying production events to examine differences before switching environments. It is a mainframe modernization product; I am not claiming that Garden uses it or needs that infrastructure.
The useful principle transfers: define what should agree before deciding that a replacement is ready. Screens that look similar provide a weak comparison. A household relationship, an assignment response, and a staff-visible exception provide more meaningful ones.
Some differences will be intentional improvements. Record those explicitly. Otherwise a comparison can reward preserving an old bug or flag a deliberate correction as a regression.
For a scheduling workflow, I would begin with an isolated, synthetic scenario: a service with several roles, a person unavailable that day, a decline, and a late replacement. Run the agreed sequence through both implementations, using supported test environments or an approved reference export. Compare the resulting assignments and response states. Keep outward effects contained. A rehearsal must not send real invitations, charge a payment method, or create operational records that staff could mistake for live work. Replaying an event safely requires control over its downstream effects; copying the input alone does not provide that control.
Then midway. Have one operator make a permitted correction. Resume the transition and ask whether that correction survives. A happy-path import cannot answer this question.
I would preserve a small evidence packet: the input version, transformation version, expected relationships, actual differences, and the decision on each difference. This gives the next attempt something concrete to learn from. An AI coding assistant can help repair a mapping against a reproducible example instead of repeatedly guessing what “migration broken” means.
The hardest moment may come after the switch. Once staff enter new information in the replacement, returning to the old application can strand those changes.
Before the rehearsal, choose how writes will work during the transition. A short maintenance window may be simpler for a small workflow than building synchronization. A longer coexistence period may require explicit ownership by workflow and a supported way to transfer subsequent changes. The right choice depends on how much interruption the organization can tolerate.
For every cutover, write down the final source checkpoint, who can authorize the switch, and what happens to edits made afterward. Define the conditions for stopping the attempt as well. A backup helps recover stored data, but a usable recovery plan must also explain what staff should do while recovery happens. Avoid casually making both systems writable. Without a conflict rule, two functioning applications can quietly create competing records of the same work. Where automated reconciliation is unavailable, a clearly assigned manual reconciliation step may be the more honest design.
Small teams can use AI to produce more candidate implementations. That shifts attention toward the quality of the acceptance process: which workflow was exercised, which exceptions were found, and whether the people operating it can recover when something goes wrong.
An extra rehearsal costs time. Maintaining two environments costs effort. Those costs should be weighed against the disruption of discovering an ownership conflict during actual operations. A phased replacement can keep each rehearsal narrow enough to understand, though it also extends the period when the team must manage coexistence.
The useful milestone is a workflow the organization can carry through a change: someone owns it, its important differences are explained, and the next operator knows what to do when the rehearsal stops going to plan.