Don't remove the files! In simply recovery mode, the transaction log files are still used by SQL, they are simply being discarded periodically, even without log backups, so as not to consume to much disk space.
Yes, you can just go in and change the recovery model in the GUI while the database is online, should not be a problem.
Seeing that the recovery model is set to simple and msdn states that the simple recovery model does not support point-in-time recovery - Does this mean that I won't be able to use my transaction log backups to restore the database in a disaster to an hour before it happened?
Even taking a transaction log backup is not supported for databases using the SIMPLE recovery model. This is a restriction of the database engine based on how this recovery model works, and the recovery features it doesn't support, as you mentioned.
A transaction log backup maintenance plan task automatically skips databases in SIMPLE recovery to avoid causing errors.
Which backup should be done first, the database backup or the transaction log backups? Articles that I'm busy reading say I should do the database backup first and then the transaction log backup else I will get maintenance plan errors, but I'm currently first backing up my transaction logs and then data databases and I'm not getting any errors.
For the reasons I mentioned above, it won't matter for databases using SIMPLE recovery, as they will be skipped by the transaction log backup task.
For databases in the other two recovery models, a full backup must exist before you start taking transaction log backups (just the first time), or you will get an error -- this is probably what the articles refer to.
Point-in-time recovery ability is normally driven by business need -- in other words, you determine how critical the data is and how much you can afford to lose, then set the appropriate recovery model to meet those needs, and finally create a backup solution.
Even though SIMPLE recovery does not support point-in-time recovery, if an hour of data loss is okay, perhaps a differential backup solution could work for you. (There are far too many variables that go into developing this kind of solution to give you a complete picture with what was provided in the question.)
Best Answer
IMHO you
MUST take transaction log backup before swithching to simple recoveryit would help you in PIT recovery as well as its documented and recommended in BOL Article. It wont do any harm and you will have a failsafe.Please also note its advisable to change recovery model when load on database is relatively less. Although you can change it in peak hour but changing recovery model does takes lock on database and if load is high you might face delay.
No transactions/changes would be lost, if you change from full recovery to simple. Changing recovery model would force a checkpoint which would commit transactions which can be committed. After changing recovery model to simple automatic checkpoint would truncate transaction logs(if no long running transaction is holding the logs)
Point 3 and 4 are totally not required, do you have specific reason to do it ?
Point 5 is necessary and you must at least take full backup daily of database in simple recovery. However backup of database should be according to RPO and RTO agreed. You can also take differential backup in simple recovery to reduce RTO.