何をどこまで改修するのか､にもよるのですが､ぱっと思いつくのはﾊﾞｰﾁｬﾙﾎｽﾄかなぁ｡

例えば､既存が www.example.com だったとして､改修後のｺﾝﾃﾝﾂを new.example.com でｱｸｾｽできるようにしておく｡

で､new.example.com で正常に動くのを確認したら､www.example.com が改修後のｺﾝﾃﾝﾂを指すように変更する｡

確認作業に使う端末側の hosts ﾌｧｲﾙ(UNIX 系 OS なら /etc/hosts､Windows なら C:\Windows\System32\drivers\etc\hosts)に､new.example.com の行を書けば､外からｱｸｾｽする人は､new.example.com では通常はｱｸｾｽできないので､作業中のｺﾝﾃﾝﾂにｱｸｾｽしてしまうことは無い｡

あと､MySQL 側がどうか？ というのはあります｡例えば､ﾃﾞｰﾀﾍﾞｰｽのﾃｰﾌﾞﾙ構造に変更があるような場合､どうしても､停止時間を設ける必要があるかもしれません｡DB 変更用の SQL 文を予め用意して､止めている間にその SQL 文を実効して､ﾊﾞｰﾁｬﾙﾎｽﾄを変更して､という感じかなぁ｡

その停止時間も嫌なら､旧 PHP ﾌﾟﾛｸﾞﾗﾑで問題が発生しなような DB､ﾌﾟﾛｸﾞﾗﾑの設計をして､DB を先にｱｯﾌﾟｸﾞﾚｰﾄﾞして｢旧ﾌﾟﾛｸﾞﾗﾑ｣?｢新 DB｣の状態を作ってからｺﾝﾃﾝﾂの修正､といった感じになると思います｡

/b/以下からのｱｸｾｽはrequire('/home/***.com/a/?')となっていても全て/b/にﾘﾀﾞｲﾚｸﾄする方法があればよいのではと思います｡

httpｻｰﾊﾞにApacheをご利用なら､mod_rewriteを使ってﾘﾀﾞｲﾚｸﾄするか､そもそもmod_aliasで指し示す物理ﾊﾟｽを変更してしまえば実現可能です｡

しかし､この方法はおすすめしません｡
なぜなら /b/ は開発環境であり､それを丸ごと公開するというのはﾘｽｸが大きすぎます｡

せっかく大規模改修するのでしたら､ﾘﾝｸは相対ﾊﾟｽにして､本番環境と開発環境は共存できるようにすることをお勧めします｡

ｻｲﾄのﾒﾝﾃﾅﾝｽは､以下の手順で行うことが多いです｡

1. 本番環境と開発環境を分ける｡
2. 開発環境で十分なﾃｽﾄを行う｡
3. 本番環境を停止する｡(代理ｻｰﾊﾞを立てることが望ましいが､それが難しいならmod_aliasですべてのｱｸｾｽをﾒﾝﾃﾅﾝｽ中ﾍﾟｰｼﾞにｱｸｾｽするようにさせる)
4. 開発環境を本番環境へｺﾋﾟｰする｡
5. 本番環境を再開する｡