Coexistence and Migration In short: A big app has a lot of forms, and a form is exactly the kind of code where a rewrite brings back bugs that testing will not catch. So the important question is not "how do I convert this form?" — it is "what should I leave alone, and how do the two systems live together?" The default position Reactive Forms is not going away. It still gets fixes, and an enormous amount of production code and many outside libraries use it. Signal Forms is the better tool for new work. That is the whole recommendation. In practice: New forms — Signal Forms Forms you are already rebuilding — migrate while you are in there Forms that work — leave them Forms relying on a library built on — leave them until the library catches up A project with both is not a project in a bad state. It is a project migrating sensibly. — both systems in one form For a form that is mostly convertible but has one field you cannot move — an outside date picker, or a complex custom field — lets a live inside a signal form: Values, , , and validity stay in step both ways. The rest of the form is ordinary Signal Forms. The limit: you cannot apply signal-form rules to a field. Its validation stays on the control. So will not work — put the validator on the as you would have before. That is a fair trade, since the reason you are wrapping it is usually that its validation already works. — the other direction The mirror image, for a form that is still Reactive Forms overall but where one part is easier with signal validation: Useful when a shared address or payment section is migrated first and has to keep working inside forms that have not been. Opting a field out connects through when there is one, so outside fields generally work. When that fights you, opt out: Signal Forms then talks to the element directly. Migrating a form The order matters , because it lets you check correctness at each step. 1. Write the data interface first. It usually already exists as your server type: If the and the server type disagree, you have just found a real bug. That is Problem 1 showing itself. 2. Move validators one at a time, and read them carefully. This is where the risk is. Check whether your custom validators had subtler behaviour than they look: 3. Move cross-field checks from the parent to the field. This is a genuine improvement, not just a translation — the error moves to the field that is wrong, so how you show it changes too: 4. Rewrite the template. Mechanical: becomes , and disappear, and errors change from to . 5. Turn into a plain list , and replace subscriptions that calculated things with . 6. Update tests. Often the biggest chunk — but usually simpler afterwards, since you can set the data directly instead of driving controls: What to watch for Disabled fields and your data. in Reactive Forms left out disabled controls — that is why exists. In Signal Forms your data always holds the complete object, so includes disabled fields. If a request depended on disabled fields being dropped, you now have to remove them yourself. This is the most likely silent behaviour change in a migration. for auto-saving. Bridge it where you still want operators: Or use v22's for the simple case. Outside form libraries. Anything built on — form builders, data-driven form renderers — has no Signal Forms equivalent yet. Those stay where they are. Do not rewrite for its own sake Forms are dense with accumulated correctness. A validator that looks odd is often odd because of a real bug report. Migrate when there is a reason — a form you are rebuilding anyway, a form whose validation complexity is causing real trouble, a new feature. Migrating a working form just to be modern is a way to spend a sprint bringing back bugs somebody already fixed. The architect's view The decision worth making explicitly is which forms you will not migrate. Left implicit, "we're moving to Signal Forms" becomes an unbounded piece of work that competes with product delivery and stalls half-finished. Write the rule down: > New forms use Signal Forms. Existing forms migrate only when we are already reworking them. Forms depending on -based libraries stay until those libraries move. That rule bounds the work and makes a mixed codebase a deliberate state rather than an embarrassing one. Why forms specifically deserve this caution. Most code you can rewrite and test. Form validation is different: the rules encode business decisions accumulated over years, often undocumented, frequently from bug reports. A validator that looks wrong is usually right for a reason nobody remembers. Rewriting from scratch loses that, and the loss surfaces as regressions in edge cases your tests never covered. The one silent behaviour change to plan for. in Reactive Forms excludes disabled controls — which is why exists. A signal form's data always contains everything, including disabled fields. If a request depended on disabled fields being dropped, that behaviour is gone and nothing will tel…