That's why you make a... well... for lack of a better word, LOOSE interface attached to your program. I'm imagining this as a piece of hardware instead of software... maybe that's why you're not understanding me. I have a rather lengthy metaphor that might help you understand what I'm suggesting. If you don't get it, then I will leave you be with the understanding that I am simply not a software engineer.
Imagine what you've already written as a wall covered with connection points hard-wired to locations on the rom. Above each location point is a screen that translates the data being streamed from the rom to the connection point into something humans can understand. Now... at the moment, your program is as rigid as lead plumbing from beginning to end. You can change the information stored in each location on the rom, which is all well and good, but it requires the person using your tool to conform to the rom and not to the tool. What if instead of having those display screens screwed immovably to those data transferring pipes, you were to run infinitely expandable and tangleproof wires between the displays and the connection points. Then you could move the display screens around to any order or position you wanted! Lemme whip up a graphical example:
Arranged by order in the Pokedex:
Arranged first by type alphabetically, and second by name alphabetically:
Arranged by name alphabetically:
Each picture of the Growlithe is linked to the very same spot, but I am able to order it where I want it without severing the link. That's how your move list should be. Each move AS IT IS LISTED is a link to its corresponding fixed location. It never has to relearn its initial location, because that bit of data is not tampered with.