I don't feel qualified to answer your question definitively so please be careful using the information I provide, but I do have some experience in managing the sort of changes you might be looking at. AFAICS however your statements should protect you against XSS and SQL injection if what you say is true.
I have recently begun the process of migrating an entire large application from mysql_ to mysqli_ and in doing so I have also set the goal that all user input shall go through prepared statements.
EDIT in response to YCs fair comment below: For the avoidance of ambiguity, I always put anything that a user has generated through a prepared statement, even if it has already been stored in the db. Where possible I avoid using re-insertion of user data though as it is unreliable so system functions tend to depend on automatically generated indices.
In fairness, the pages are short (no more than 1000 lines) so fixing does not take long per page and they have few queries so the performance reduction is not noticeable, and certainly eaten up by improvements in server technology since I wrote the original code. I suspect you will find that the reduction in escaping etc will far outweigh any performance hit on prep statements though you'll have to check if it's critical.
It has dismayed me how many vulnerabilities I found in my code whilst doing this review (I included security as best I could when it was written and set myself rules much the same as yours) and ultimately I have found the need to rewrite large code chunks to improve security. Performance has improved markedly as a result of greater experience and code tweaks too.
The way I'm going about the change is to add a mysqli connection to my database header file. All new code uses this. As I find time, I'm updating older code and testing each page using a header file that does not have the old mysql connection. It's dead quick to find bits you've missed that way in a dev environment and it can be quite a good way to use time that would otherwise be wasted as each page takes only a few minutes to update so can be done during brain-fade periods.
A note on the second order injection BTW as this was the most common vulnerability I had built in:
Most SQL injection prevention kind of assumes that the injection attack will only take place at login, from a malicious non-registered user who once foiled will never return and that registered users can be trusted. Not so.
It is conceivable that code could be injected through your protection then used later. This is most unlikely to work as it is heavily dependent on clumsy db and application design, but some of the smartest people in the world are hackers. Why make their life easier?
The attack is made more probable if your sql is simple and your application does any subquerying using data previously obtained from the db. Remember that
' OR 1=1 gets converted to
\' OR 1=1 by mysql_real_escape_string but is stored as
' OR 1=1 in the db
so if retrieved and placed into a PHP variable which is then used unescaped in a sql query, it can then cause problems just the same as if it had never been escaped. If you just use prep statements for all queries, the risk goes away permanently though do remember the prep statement will still store the malicious code so you still have to use a prepared statement again when you next need to use the data that has been entered.
This Blog gives a decent discussion and examples so I'll not expand further, but if you ensure that all user input data is passed through prepared statements if it is to be used as part of a query, even after it has been stored in the db, you should be safe.
At the risk of repetition, it is worth also becoming very friendly with the OWASP site which has valuable security discussions.
