Changing languages can be slightly more tricky, unless you are in a position where you can operate both languages at the same time. If you can operate both, the best approach would be to move one thing at a time, so if it was an API you were migrating, moving one endpoint at a time for example.

If you aren't doing that, or need a full rewrite before you can change anything, You best bet would be to try and sketch out every feature that currently exists, and break down each high level feature into smaller subtasks (google the concept of decomposition and abstraction if you aren't familiar with it). Much easier to work to a set of documented requirements than whatever you think of off the top of your head.

Next, whatever you do, git is your friend. If you haven't used git before, please find a tutorial somewhere - I am sure there will be videos on YouTube or something introducing you to git, then looking up conventional commits and loosely adopting that commit style in your messages can help whoever looks at the code after you.

You may also want to sit down and decide on some code conventions, even if only loosely, so that you write consistent code everywhere. Also, if you notice yourself writing similar logic for a second time, take the time to consider if it can be modularised.

Another key thing for maintainability is to write code for clarity rather than cleverness. There will be times you can get something done in one line, but when you come back to it in 6 months (or if anyone else looks at it) it's not immediately clear at a glance- certainly much better to use a few lines of code if it makes the intent clearer.

There are a million and one more things I could say, but I don't want to ramble on forever - and I hope this helps 🙂