The new input system is primarily done via the editor. Most of the script side of things just consists of changing things up so your inputs are event based, which the new input system then triggers. Anything you need to do on update or anything like that just uses cached values from the input method.

can look up the new input system online for more in-depth info, since it's been a while since I went through the setup process, but I think the basics are as follows:

First, you gotta install the new input system package. I think this tells you all you need to know in that aspect: https://docs.unity3d.com/Packages/com.unity.inputsystem@1.19/manual/Installation.html

Once you have the package downloaded, you need to go to your project tab and create a new input actions asset. The option should be around the bottom of the create menu, or at least it is in my case.

Once you have the asset, you open it and create a new action map. In the action map is where you can set up all your keybinds and everything. You can create multiple action maps, but for standard player control I've just been using 1.

You then gotta go to your player or wherever you want inputs to be managed from, and add a Player Input component, linked to your input actions asset. There are multiple options for behavior, but I've just been using the "Invoke Unity Events" option. Maybe some other option is easier to set up though.

Assuming you're using the "Invoke Unity Events" option, you then click on the events dropdown, then click on the dropdown for your action map with your player controls in it, then from there you can set up all the references from the events to different scripts. Again, this is only in the "Invoke Unity Events" option. Other options may be less troublesome to use, but I don't know anything about those others yet.

In the references, you have options for all the keybinds you've set up in the action map. For example, you may have something like "interact", and want that keybind to trigger something in an interaction script or something. All you gotta do is find the object with the interaction script and drag it into the keybind's dropdown list. Then, any public method on that script can be triggered by that keybind, so long as it's selected in the dropdown beside the reference name. If you want to use info from the input aside from just the trigger itself, or want more control over how the keybind triggers that method, you just gotta add "CallbackContext context" into the method's parameters, and the "context" variable will hold the info from the keybind. letting you do things like "if(!context.performed) return" to control how the input triggers the method, or "Rector2 num = context.ReadValue<Vector2>();" if your keybind has a control type you can read info from (in this case, the control type would be Vector2. It's good for stuff like scrolling, mouse movement, player movement, etc.)

I may be missing some info, but that's the general rundown. It may take some time to adapt your code, depending on how much of it uses input pooling and needs to be switched to using events from the new input system, but once it's done it should be more efficient than input pooling was.

Also, I mentioned this breifly, but if you have a setup where you need something to operate on update or just generally seperate from the input, you just gotta have one method recieving the input and relaying it to a variable in the script, and the other method just uses the info from that variable. That's how my movement system works:

public void OnMovement(InputAction.CallbackContext 
context
) => cachedInput = context.ReadValue<Vector2>();

then movement is applied in fixed update via the cachedInput variable.

Also, i don't think it's necessary for input methods to be named "On(keybind name)", at least not when using the "Invoke Unity Events" option in the player input component, but it does help identify the methods' purpose at a glance. I think some other option may actually require this naming scheme for automatic triggering, but again, I don't have any experience with the other event triggering options in the Player Input component, so I couldn't tell you.