O software geralmente não é autocontido, já que normalmente é necessário (por design do sistema) gravar dados nos caminhos do sistema e do usuário, no registro (para registrar alguns recursos no sistema atual), no caminho temporário, etc ...
Alguns softwares podem ser portados redirecionando esses dados para o caminho temporário, ou dentro do caminho do programa, mas isso depende muito do design do próprio programa, se isso for possível ou não.
Então, quando você copia a pasta do Office, você perde muitos dados escritos em outro lugar, é por isso que não funciona simplesmente copiar a pasta em outra máquina.
Mas, ao copiar dados, você não tem esse problema; se o usuário puder ler os dados, poderá copiá-los usando o gerenciador de arquivos do sistema ou muitos outros truques, mesmo que você tente torná-lo deliberadamente difícil. acessar com um serviço de terminal para um programa específico apenas), desativar portas USB, usar dados vinculados em outro lugar, etc - como todo método de proteção tem suas deficiências.
A maneira mais extrema de fornecer dados sem a capacidade de copiá-los seria usar uma camada de apresentação remota, como um frontend de website ou um aplicativo da web para mostrar os dados aos usuários autenticados, mas em qualquer caso o usuário pode anotar os dados - até mesmo gravar por registro, usando alguma automação - e você precisa verificar cuidadosamente a segurança de sua solução (coisa mais óbvia, ataques de injeção de SQL ao seu banco de dados).
Resumindo, quando o usuário pode ler os dados, você não pode ser muito eficaz em impedi-lo de lançar uma solução para exportá-lo - o melhor que você pode fazer é 1) ser seletivo sobre quem acessa os dados e 2 ) rastreie suas consultas de dados para detectar possíveis abusos.