CAPES O vendor lock-in é uma situação em que os clientes se tornam dependentes dos serviços e recursos de um provedor de nuvem. Como solução para esse problema, uma estratégia é que esses clientes distribuam seus dados e aplicações entre nuvens diferentes, no entanto neste caso, estes precisarão lidar com a heterogeneidade das nuvens, usando as diferentes ferramentas fornecidas por cada um desses provedores, para gerenciar, muitas vezes manualmente, toda essa infraestrutura distribuída. Outra estratégia é usar um serviço multi-nuvem, capaz de lidar com toda a heterogeneidade entre nuvens de maneira transparente para o cliente, fornecendo uma interface unificada capaz de gerenciar as diferentes nuvens simultaneamente, como no caso de migrações de máquinas virtuais entre nuvens. Este trabalho de dissertação propõe uma arquitetura chamada Kumo para simplificar a migração de máquinas virtuais entre várias nuvens, que quando implementada, simplifica o processo de migração dessas máquinas entre nuvens para o operador em nuvem. Para isso, neste trabalho, os dois componentes projetados na arquitetura são implementados, a interface da linha de comandos e o serviço multi-nuvem de migração de máquinas virtuais. Além disso, foram desenvolvidas integrações com as três nuvens públicas mais usadas atualmente, Amazon Web Services, Microsoft Azure e Google Cloud Platform, o que tornou a migração homogênea e automatizada entre essas nuvens da perspectiva do operador. Para avaliar a solução, foram utilizados os data centers dessas três nuvens nos estados americanos da Virgínia e Califórnia. Com o objetivo de definir um cenário real de uso de Kumo, foram realizadas migrações da costa leste para a costa oeste dos Estados Unidos. Como a migração realizada com a VM em execução (live) ainda não é tecnicamente viável, as migrações realizadas neste trabalho foram feitas com a VM desativada (non-live). A métrica usada foi o Tempo Total de Migração (TTM), que é o tempo desde que a migração é iniciada na nuvem de origem até a máquina virtual ser criada na nuvem de destino. Essa métrica é um fator importante na decisão de quando e para onde migrar, ou mesmo, se o tempo de migração apresentado pela métrica for muito significativo, recriar todo o ambiente no destino, transferindo os dados e reinstalando as aplicações apropriadas. Como resultado, entre os cenários homogêneos, aqueles em que a nuvem de origem e destino são do mesmo provedor, mas em diferentes data centers, o melhor resultado ocorreu nas migrações entre nuvens da Azure, com um TTM mediana de 45 minutos e 59 segundos, enquanto nos cenários heterogêneos, o melhor resultado ocorreu nas migrações da Google Cloud para a Amazon, com TTM mediana de 45 minutos e 56 segundos. The vendor lock-in is a situation where customers become dependent on the services and resources of a cloud provider. As a solution to this problem, a strategy is for these customers to distribute their data and applications among different clouds, however in this case, these customers will need to deal with the heterogeneity of clouds, using different tools provided by each of these providers, in order to manage, often manually, all of this distributed infrastructure. Another strategy is to use a multi-cloud service, which is able to handle all the heterogeneity among clouds in a transparent way for the client, providing a unified interface capable of managing the different clouds simultaneously, as in the case of machine migrations between clouds. This dissertation work proposes an architecture called Kumo to simplify the migration of virtual machines between multi-clouds, which when implemented, simplifies the process of migrating these machines between clouds for the cloud operator. For this, in this work the two components designed in the architecture are implemented, the command line interface and the multi-cloud virtual machine migration service. Also, integrations were developed with the three most used public clouds nowadays, Amazon Web Services, Microsoft Azure and Google Cloud Platform, which made the migration homogeneous and automated between these clouds from the operator’s perspective. To evaluate the solution, the data centers of these three clouds in the American states of Virginia and California were used. With the objective of defining a real scenario of use of Kumo, migrations were performed from the east coast to the west coast of the United States. Because the migration conducted with the VM running (live) is not yet technically feasible, the migrations performed in this work were conducted with the VM turned off (non-live). The metric used was the Total Migration Time (TMT), which is the time since the migration is initiated in the source cloud until the virtual machine is created in the destination cloud. This metric is an important factor in deciding when and where to migrate, or even, if the migration time presented by the metric is very significant, recreate the entire environment at the destination, transferring the data and reinstalling the appropriate applications. As a result, among the homogeneous scenarios, which are those scenarios where the source and destination cloud are from the same provider but in different data centers, the best result occurred in migrations between Azure clouds, with a median TMT of 45 minutes and 59 seconds, while among heterogeneous scenarios, the best result occurred in migrations from Google Cloud to Amazon, with a median TMT of 45 minutes and 56 seconds.