Read the code before you port it
A lot of InfoPath code-behind exists because the designer of the day could not express the logic any other way. Showing a field conditionally, copying a value between fields, making something required only sometimes, totalling a couple of numbers. All of that needed code once. None of it does now. So start by reading the old code and deciding what still has a reason to exist. Porting comes later, if at all.
Sort it into three piles
| Pile | What lands here | What you do |
|---|---|---|
| Rules already do this | Show and hide, enable and disable, required-when, calculated values, cross-field checks | Delete the code. |
| Still needs script | Genuinely bespoke behaviour the rules cannot express | Rebuild it in the code editor against the form JavaScript API. |
| Belongs somewhere else | Work that ran server-side, or reached systems a browser should not touch | Move it off the form. A Power Automate flow on the list takes over after save. |
The first pile usually takes most of it. Script you do not have is script nobody has to maintain in three years. The rules builder and validation rules cover what goes in that pile.
What the code layer gives you
For the second pile, Forms365 Workspace has a code editor for HTML, CSS, and JavaScript, with a JavaScript API for reading and writing the form. It is an escape hatch, deliberately, and it is there for the behaviour the visual rules genuinely cannot express rather than as a general-purpose extension point.
The difference that occasionally bites
InfoPath code-behind was managed code. This is JavaScript running in the browser while somebody fills the form in. For form behaviour, which is what nearly all of that old code was actually doing, the distinction does not matter. It matters when the old code did work that belonged on a server. That is the third pile, and the answer there is to move the logic rather than port it: the form captures and writes to the list, then a flow on that list carries on.
A sensible order of work
Rebuild the form with rules and leave the code editor closed. Get the ordinary path working, then look at what genuinely remains. Porting the script first tends to recreate workarounds for a limitation that no longer exists, and you finish with code you never needed.
The other two hard parts of an InfoPath migration have their own walkthroughs: repeating tables and views and tabs. For the wider move, start at the InfoPath alternative overview.
Try the rules before the code.
Free for 14 days. No card, and no Power Apps licence.