Il n'y a pas de réponse facile à votre question car pratiquement toutes les façons simples de le faire impliquaient de faire les choses différemment lors de la rédaction de l'application.
Si vous avez des appels directs aux fonctions mysql_* dans votre code et aucune couche d'abstraction de base de données où vous effectuez vos requêtes via une classe ou une fonction d'assistance, vous devrez modifier chaque commande.
Vous ne pouvez pas vous contenter d'ajouter un i à des commandes comme mysql_query en procédant comme mysqli_query() nécessite que le premier paramètre soit le lien vers la base de données où avec mysql_query() si une connexion était donnée, c'était un deuxième paramètre.
Au lieu de simplement changer mysql_query(...) en mysqli_query($link,.....), je recommanderais qu'il n'y ait pas de meilleur moment pour mettre en place une couche d'abstraction db. Utilisez donc des fonctions, par exemple sql_query() qui traitent réellement vos requêtes. Ainsi, à l'avenir, si vous devez modifier à nouveau la base de données, vous pouvez simplement mettre à jour les commandes spécifiques à la base de données dans un fichier d'abstraction. De cette façon, si vous écrivez une fonction qui enveloppe mysqli_query, vous pourrez simplement renommer votre mysql_query() en votre fonction d'assistance et laisser la fonction d'assistance s'occuper d'y mettre le lien.
Bien que ce soit le moyen le plus simple, il ne liera pas de paramètres ni ne préparera d'instructions, ce qui est un facteur majeur dans la prévention des vulnérabilités d'injection sql
Une fois que vous avez modifié toutes ces commandes, vous devez tester.
Si vous n'avez pas écrit de tests automatisés, c'est probablement le bon moment pour commencer à les écrire. Même si vous devrez vérifier que chaque changement a fonctionné, si vous le faites par un test automatisé, vous pouvez éviter cette douleur à l'avenir.
