Existem basicamente 3 caminhos a seguir:

Versão 1:"old school":PHP-Gtk+ e bcompiler

• primeiro, se ainda não o fez, você precisa separar sua lógica de negócios da camada de apresentação (HTML, mecanismos de modelagem, ...) e da camada de banco de dados
• Adapte sua camada de banco de dados, para que ela possa viver com um banco de dados alternativo (o SQlite local vem à mente) e realizar a sincronização quando estiver on-line novamente
• Finalmente use PHP-Gtk+ para criar uma nova UI e empacotar tudo isso com bcompiler

Versão 2:"Padrão":leve seu servidor com você

• Olhe para Server2Go, WampOnCD e amigos para criar um "servidor web duplo clicável" (Comece em Z-WAMP )
• Você ainda precisa adaptar sua camada de banco de dados como na versão 1

Versão 3:"Web 2.x":mova o aplicativo do servidor para o navegador

• Mova a lógica do seu aplicativo do lado do servidor (PHP) para o lado do cliente (JS)
• Torne sua parte do servidor (PHP) apenas um acesso a dados ou camada de sincronização
• Use os recursos off-line do HTML5 para substituir seu acesso a dados por dados locais se estiver off-line e para ressincronizar se estiver on-line

Qual ​​é o melhor?

Isso depende do que você tem e do que você quer. Se a maior parte da sua lógica de negócios estiver em PHP, movê-la para o navegador pode ser proibitivamente caro - esteja ciente de que isso também gera uma nova classe de pesadelos de segurança. Eu pessoalmente não recomendo transportar dessa forma, mas eu recomendo para novos aplicativos, se o banco de dados de apoio não for muito grande.

Se você optar por manter sua lógica de negócios PHP, a decisão entre 1 e 2 geralmente é uma questão de quanta interface do usuário seu aplicativo possui - se são apenas alguns formulários CRUD, 1. pode ser uma boa ideia - é definitivamente o mais portátil (no sentido de levá-lo com você). Se não, vá com 2.