Actually, your real problem is doing this in production environment. I mean, you must reduce downtime as best as possible and plan recovery (rollback) procedures in case something goes wrong.
Usually, I don't really care about "officiality" of a repository, but rather "reputation". I'm not used to think that "unofficial" public open source repos inject malware into packages (security concern), and I do think that if they are popular and widely used they are well maintained (reliability concern).
If you are really concerned about using the unofficial repo, you have a harder option: compile from source, then overwrite PHP when the official repo gets updated. This introduces a risk.
Here is my strategy.
First, make a replicable snapshot of the application. Collect files, DB entries and whatever is needed to kick-start the application on a brand new server (in case you want to load balance with 3, but you don't really want to). This will be your rollback procedure.
Second, make a server snapshot with the current PHP installation. A full system image is suitable. Keep it as a golden image. You'll backup your application along with the server, but it's OK.
Third, do the source compilation, possibly try it in staging first.
Fourth, when your official repo gets updated, make a new application snapshot, restore the old golden server image, upgrade PHP and then upgrade the application to the snapshot you just did.
If anything goes wrong you always have:
- A backup application to restore. I don't think you handle thousands of transactions per second, so loss of data may be minimal or even null
- A full server image in case something goes really, really bad