The right picture, delivered into the wrong rectangle
Resolution, crop and reserved space solve different image problems. Design all three around what the reader needs to see.
Engineering8 min read
Choose a migration small enough to disagree with
A read-only search slice can reveal whether a replacement preserves permission boundaries before the whole business depends on it. Six worked queries separate a useful ranking change from an unauthorised result.
Make the first disagreement affordable
Order search is a plausible place to start a migration because the request sounds so modest: help people find the order faster. Replacing the application that also handles stock, purchasing and invoices is a much larger answer. It may turn out to be the right one. I would still want to know what the search change teaches us before making those other capabilities depend on the same decision. A small read-only trial gives the team somewhere to disagree while the existing business can continue working.
Martin Fowler’s 22 August 2024 discussion of Strangler Fig modernisation describes gradual replacement instead of one wholesale substitution [1]. Its practical attraction is the chance to learn while the established service still works. A smaller delivery is valuable if its evidence can change the next decision. Dividing a rewrite into many tickets is easy enough; allowing one of those tickets to show that the planned rewrite is wrong is a more consequential commitment.
Consider a constructed search migration with four invented orders, each belonging to a particular account and carrying a searchable description. The old implementation is a reference behaviour, not an assertion that every legacy decision deserves preserving. The new implementation is allowed to rank results differently, but must not broaden which account can see them. That gives us a useful seam: a read capability with an explicit permission invariant and a difference that might be intentional.
The first question is therefore narrower than whether the new system is better. Can this capability move while its inputs, authority and output are understood well enough to compare? If the answer requires redesigning every stock write and invoice rule, order search may not be the independent slice it first appeared to be. Discovering that early is progress, even if it changes the preferred starting point.
Draw the ownership before the new screen
During the proposed transition, the established application remains the owner of order writes. A new search component can read a replicated view or an authorised read interface, depending on the actual system. A routing layer chooses which search result the person receives. A comparison path may execute the alternative read for observation, provided it carries the same authorisation context and is allowed to access that data.
This is a proposed read-only trial over invented records. The real routing layer would have to carry the authenticated account to both search paths, and the search copy would need an understood freshness contract. Otherwise a discrepancy could come from different permissions or different source versions rather than the replacement’s matching logic. Keeping those conditions beside each comparison makes a result interpretable: the team can disagree about ranking without first having to guess whether both searches were allowed to see the same orders.
The write boundary prevents a useful search trial from quietly becoming a bidirectional data migration. If the new screen later needs an edit button, decide where that command goes. Sending some edits to the old service and others directly to a new database creates competing ownership, even when both screens call their field status. Prefer an explicit command route through the current owner until moving that authority is a separate, understood change.
Freshness is another boundary. A search copy may be adequate for finding yesterday’s order while being unsuitable for promising the last available item. Show the relevant update or freshness state where it changes the decision, and confirm commitments against the authoritative write path. A modern interface should not turn a delayed copy into a live-stock guarantee through confident wording. Search usefulness and allocation authority need not move together.
Search can move without moving stock authority
Proposed responsibility boundaries for the constructed search migration.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
Compare the permission, not just the match
The executable fixture contains orders O1 and O4, open filter orders belonging to account A; O2, an open filter order belonging to B; and O3, A’s cancelled cable order. It runs six read queries covering the two accounts, a status filter, an empty term, a cancelled item and an attempt by A to search B’s exact order code. These cases were constructed for explanation, not sampled from a client workload.
The faulty replacement reverses the sorting and forgets account filtering. Account A’s open-filter search changes from O1 and O4 to O4, O2 and O1. A larger result count might initially look like better coverage, until we ask who owns the extra result. O2 belongs to B. The comparison keeps gained and lost identifiers separately and checks their account ownership, so it exposes the added record as a permission defect rather than a promising search improvement.
The corrected version restores account filtering and still reverses sorting. Its membership matches the old result across the six local queries, with no gained, lost or other-account records. Some sequences differ. The fixture records that difference without automatically approving it. A business may want newer results first, but pagination, staff expectations and stable ordering still need consideration before a changed ranking becomes an accepted requirement.
The exact-code case exposes the same omission. Account A searching ORD-101 received B’s O2 from the faulty search and no result from the corrected one. Knowing a precise reference does not grant permission to retrieve it. Include that route alongside broad word searches, because an implementation can apply account filtering in one query builder and forget it in another. These six constructed queries establish the local selection results; real authentication, pagination and response time still need their own checks before the route serves customer records.
A gained search result can be a permission defect
Six queries over four invented orders compare the original, deliberately faulty and corrected search. Sorting changes are recorded separately from account visibility.
Scroll sideways to see all columns.
| Query | Original IDs | Faulty new IDs | Corrected IDs | Decision revealed |
|---|---|---|---|---|
| A · filter · open | O1, O4 | O4, O2, O1 | O4, O1 | O2 belongs to B: block faulty route |
| A · cable · all | O3 | O3 | O3 | Same membership |
| B · filter · all | O2 | O4, O2, O1 | O2 | O1/O4 belong to A: block |
| A · cancelled | O3 | O3 | O3 | Cancelled filter preserved |
A · exact code ORD-101 | None | O2 | None | Exact lookup must still apply scope |
| A · all | O1, O3, O4 | O4, O3, O2, O1 | O4, O3, O1 | Corrected order differs; needs a decision |
Turn discrepancies into decisions
A comparison record should retain the normalised query, relevant account scope, old and new identifiers, gained and lost results, ordering differences and the version of each implementation. Keep sensitive query material only where needed and permitted. Support needs enough context to investigate a discrepancy without building a second uncontrolled archive of customer searches. Production observation has a data-handling cost as well as an engineering one.
Differences need classification before they can inform a rollout percentage. An unauthorised result blocks the transition. A missing cancelled order may reveal a default-filter mistake or an intentional policy change requiring agreement. Different ordering may be acceptable once its consequences are checked. An average match rate obscures those distinctions, giving a harmless ranking change and a permission failure similar numerical weight even though they demand different decisions.
I would keep the old route available in a form the people using the system can actually return to, and record which route produced a disputed result. A flag labelled rollback is less comforting if an interruption leaves someone reconstructing its configuration. The return path needs checking against the data and permissions that will exist during the trial, including changes the trial itself introduces. Otherwise the escape route may still be on the diagram after it has stopped being a usable route through the system.
Choose exit evidence tied to the outcome: permitted records remain permitted, prohibited records remain hidden, known query classes behave as agreed and discrepancies have owners. Response-time requirements should come from the real journey and measured observations, not a flattering synthetic number. If the trial reveals an entangled dependency, adjust the boundary. A small migration should be allowed to teach the team that its first assumption was wrong.
A slice is finished when it removes something
Once the agreed evidence supports the new route, retire the old search branch and the now-unused configuration, monitoring assumptions and support instructions. Otherwise the migration keeps adding systems without reducing the amount somebody must maintain. Retirement can have prerequisites of its own, particularly if an old report or background job still calls the previous interface. Find those consumers before treating the unused screen as proof that the capability has disappeared.
Coexistence has costs: two implementations to understand, comparison machinery, compatibility work and a period of operational ambiguity. For a small tightly coupled application, an internal refactor or direct upgrade may be clearer than introducing an independent service. Incremental replacement is worth those costs when the first slice can deliver something useful and provide evidence for the next decision. The system’s actual dependencies determine whether search is such a slice.
The six-query set is small enough for a product owner and an engineer to disagree about individual outcomes. If a cancelled order disappears, they can ask whether that is an intended default or lost functionality. If O2 appears for A, the account rule already supplies the answer. Replace the invented records with authorised examples from the actual search before expanding the trial. That discussion separates promises the replacement must preserve from habits the team may reasonably choose to change.
In this example, account visibility is the promise the new search must keep; ranking is a choice the team can reconsider. The established application can keep ownership of writes while those read behaviours are compared. When the evidence supports the replacement, account for the remaining callers and remove the old search path. That removal matters. It is the point at which the small migration gives back some of the maintenance it borrowed during the trial.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotReferences & further reading
Primary sources behind this article. Living documentation may change.
- Martin Fowler: Strangler Fig Published 22 August 2024
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A few more things
worth a read.
Back to the reading room 
What does £240 belong to?
A readable table preserves relationships between values, row labels, column headings and actions across different ways of reading.
When two calculations agree on the wrong answer
A shadow comparison exposes differences. Independent rule examples explain whether those differences are bugs, corrections or changed assumptions.