Removing or replacing *inzsr with Dspecs

I'm currently working through an old RPG program which was well
structured with small clean(ish) subroutines and a semi Model View
Controller style logic to handle screen control (although with hindsight
its to intermixed with data/program logic, ie SC01SR handles the screen
01, but also dependent on options also calls business logic subroutines
such as updating/adding/deleting a file)

Now when this program was created it had a very large *inzsr, to define
keylists, plists, before/store/etc. fields (b1cust, s1cust, etc.) so
than no fields were defined "in line."

My first question is... is it worth moving and re-coding all the *inzsr
into D specs at the beginning of the program as a first stage of
refactoring the code?

To my mind this makes sense, removing *likes etc from within the code to
the area most suited to having such code, especially as D specs can
perform an equivalent of *like and initial values can be set (I am
assuming a reset will work in the same way as a *inzsr defined field)
also a lot of this change, if not all, could be automated.

My second/third questions are once the above has been done, is it then
worth another refactoring exercise to replace the subroutines with
subprocedures, my gut tells me if it is then this can then be followed
by a third refactoring exercise which would be to move the initially
created global D specs into the subprocedures where appropriate to
isolate fields initially "global" but in reality local to specific
subroutine. (again I could see some of this also capable of automation)

Do these seem like a logical first steps to take, both in terms of
learning but also in a wider context of "best practise" refactoring of
code.

Jon