The increasing mobility of data, as it ping-pongs between clouds, data centers and the edge, has made it an easier target of cybercrime groups, which has put a premium on the encryption of that data in recent years.

Cybersecurity vendors have stepped up, developing strong and efficient ways to encrypt data both while it’s at rest and when it’s in transit. However, there is a glaring weakness. When the data is being processed, analyzed or used by applications in another way, it needs to be unencrypted, making it more vulnerable to attack.

To counter this, some major IT vendors are pushing forward with a decades-old encryption idea that was first talked about in the late 1970s but not successfully demonstrated for the first time until 2009. Since then, interest in fully homomorphic encryption (FHE) has increased, largely paralleling the rise of cloud computing.

Putting a Focus on FHE
FHE enables data to remain encrypted even as it is processed and analyzed, whether that’s in the cloud or in third-party environments. The data is protected against cybercriminals as well as others who are not supposed to see it. Once the mathematical operations, such as calculations, are run on the encrypted data, the results are decrypted and corrected.

In recent months, the list of interested vendors has included IBM, which in December announced its Security Homomorphic Encryption Services, a managed offering hosted on the IBM Cloud. Big Blue has been active in the development for years – it was an IBM researcher who ran the 2009 demonstration – and earlier last year conducted successful FHE field trials. The company also released an FHE toolkit for Apple’s MacOS and iOS operating systems, with Android and Linux being added later.

“Fully homomorphic encryption holds tremendous potential for the future of privacy and cloud computing, but businesses must begin learning about and experimenting with FHE before they can take full advantage of what it has to offer,” IBM Security CTO Sridhar Muppidi said in a statement at the time.

Microsoft’s SEAL (Simple Encrypted Arithmetic Library) is another such effort, an open-source software library created by researchers at the company that uses multiple forms of homomorphic encryption. It’s available on GitHub.

DARPA Gets In on the Effort
Intel, which has been adding security features to its silicon for years and has been working on FHE techniques, was picked earlier this year by the federal Defense Advanced Research Projects Agency (DARPA) to work with Microsoft to create an ASIC chip for homomorphic encryption. DARPA will use the accelerator in DARPA’s Data Protection in Virtual Environments (DRPIVE) program to create the hardware needed to reduce the compute power and time that currently is required to run FHE operations. Intel will lead one of four research teams; the other three will be headed by software makers Duality Technologies – which uses homomorphic encryption in its Duality SecurePlus platform – and Galois and a Silicon Valley-based nonprofit scientific research institute, SRI International.

Earlier this month, Google released a collection of open-source libraries that can be used to implement FHE in modern workloads and made them available on GitHub.

“As cloud computing services continue to see widespread adoption, it becomes increasingly important for service providers to guarantee the security and privacy of the data of their customers,” Google researchers wrote in a paper released on GitHub.

Homomorphic Encryption a Long Time Coming
The FHE demo in 2009 proved the technology could work, but it was too slow and consumed too much compute power to be put to use and it was too expensive and required expertise in cryptography. However, such challenges are being addressed.

“Fortunately, over the last few years, FHE has become less computationally intensive, due to significant progress in hardware acceleration, efficient optimizations, and low-level implementations,” the Google researchers wrote.

Still, they added, for adoption of FHE to be widespread, tools are needed to enable software developers without cryptographic expertise to integrate homomorphic encryption into their applications. Dirk Schrader, global vice president of security research at New Net Technologies, agreed. He said a hurdle will be the application of FHE “where the analytics of large data sets will be used for benchmarking individuals, as seen in all those fitness applications or health monitors. Consumerization has the intrinsic tendency to include the question of cost of operation and maintenance, and applying high-end cryptography requires solid knowledge and development skills.”

Digital Health Projects to Benefit
Despite the remaining hurdles, Google, IBM, Microsoft and others are pushing to make it easier for developers to leverage the technology. Bringing FHE to the point where it could be used by vendors and developers would be helpful to organizations in a range of industries, Schrader, whose company makes cybersecurity and compliance software, told eSecurity Planet.

FHE “can solve some of the pressing issues arising out of the conflict to analyze large sums of data points generated by many individuals,” he said. “Many countries are considering some kind of digital health initiatives, where the promise to find better cures is countered by the fear [of losing] privacy. [Homomorphic encryption] offers an interesting approach here by allowing the analysis of encrypted data for purposes that are not related to an individual data set.”

Other possible uses include autonomous public transportation analyzing users’ locations to predict the load in a highly populated urban area, he said, adding that big data “is based on the promise to distill previously undiscovered opportunities from large amounts of data and has, so far with good reason, earned criticism from data privacy advocates.”

A Small but Growing Market
The FHE market is small but expected to grow in the coming years, with market research firm The Insight Partners predicting it will increase from $120.12 million in 2019 to $246.29 million by 2027, an average of 9.7 percent a year. Most of the use will be in North America and Europe, though the Asia-Pacific region stands to see the fastest growth. IBM noted that Gartner forecasts that while currently fewer than 1 percent of companies have the budget for projects that include FHE, that number will be more than 20 percent by 2026.

All this is happening as businesses increasingly adopt hybrid cloud and multi-cloud strategies. In its annual State of the Cloud report, IT management software maker Flexera found that 92 percent of enterprises have embraced a multi-cloud environment and 80 percent have hybrid clouds. Meanwhile, the number of government regulations and standards, such as the European Union’s General Data Protection Regulation (GDPR) and California’s Consumer Privacy Act (CCPA), are putting growing pressure on enterprises to ensure that the data they collect, store, analyze and act on, is protected from bad actors and prying eyes. Being able to leverage FHE would give them another tool to use to do just that.

Background: A Small Business Forced to Move

The client — referred to here as Progress Accounting — is a small accountancy firm based in Australia with just over ten staff across a main office and two smaller branch offices. They were running five servers in a VMware-based hosting environment approximately 70 miles away in Brisbane, alongside Office 365 Business Premium for email and collaboration.

The trigger for migration was straightforward: their hosting provider was changing its business model and asked them to move their workloads elsewhere. An upcoming office relocation delayed the project by a few months, but the migration ultimately went ahead. The hosting company had already run Azure Migrate — Microsoft’s free assessment service — to evaluate existing workloads, recommend equivalent Azure VM sizes, and estimate monthly costs. That report became the starting point for the migration planning.

Lesson 1: Azure Migrate Is a Starting Point, Not a Final Answer

Azure Migrate gives you a useful baseline: VM size recommendations and rough cost estimates. However, the tool assesses workloads based on observed performance and disk sizing, and it cannot account for application-level requirements, licensing constraints, or architectural decisions you may want to make during the migration — such as consolidating servers or changing how users authenticate. Treat the report as an input to your planning, not a migration plan in itself.

Lesson 2: The Current Identity Model Isn’t Always the Right One Going Forward

One of the first significant decisions was around identity. Rather than extending or replicating their existing directory into Azure, the team evaluated what the workloads actually needed. Because their line-of-business (LOB) application and its data were already protected by Multi-Factor Authentication (MFA) native to the application itself, the decision was made to use local Windows accounts on the migrated servers instead of deploying Azure Active Directory Domain Services or a domain controller VM.

This is a reminder that lifting and shifting an identity model along with the servers is not always necessary or desirable. Simpler setups can reduce management overhead and cost — provided the security requirements are genuinely met by an alternative approach.

Lesson 3: Don’t Rely on the Previous IT Provider to Do the Job

The scope was narrowed to two Windows Server 2016 machines: one running Citrix (to be converted to a Remote Desktop Services Host, RDSH) and one running SQL Server supporting the LOB applications. File shares were consolidated onto the SQL Server to reduce the number of servers to manage.

The hosting company offered to perform the migration over Christmas at no charge. Access to the Azure subscription was provided and configuration details were shared. After several weeks of silence, the team followed up and found that no migration work had been done — attributed to “lack of time.”

The lesson is unambiguous: when a migration is critical to a client’s business continuity, do not outsource the execution to a third party without clear accountability, agreed milestones, and regular check-ins. If you own the outcome, own the process.

The Migration: Using Azure Site Recovery for VMware-to-Azure

Because direct access to the hosting infrastructure was not available, the team asked the hosting company to deploy Azure Site Recovery (ASR) using the OVA-based Process Server/Configuration Server template designed for VMware-to-Azure migrations. Once in place, replication was configured for the two VMs.

One support incident arose when someone attempted to reinstall the replication agent on a VM where it was already installed. This broke the trust relationship between the agent and the process server — a known ASR gotcha.

Lesson 4: Don’t Reinstall to Fix Problems — Investigate First

The instinct to “just reinstall” when something is broken is understandable but dangerous in an ASR context. Reinstalling the Mobility Service agent over an existing installation can corrupt the agent-to-process-server trust and require Azure support involvement to resolve. Always check ASR logs and the Azure portal for specific error codes before taking corrective action.

Once replication was stable and the on-premises disks were in sync with Azure, test failovers were performed. During testing, the VMs were moved to a workgroup, local accounts were created, hosts file entries were added so the two servers could locate each other, Citrix was uninstalled, RDS Client Access Licenses (CALs) were applied, existing user profiles were linked to the new local accounts, and file shares were recreated.

One architectural limitation worth noting: ASR test failovers are designed to be temporary — the test VMs are expected to be deleted after validation. In this case, significant configuration work had been done on a test-failover VM that the team wanted to keep. ASR does not make it straightforward to promote a test failover VM to production. Plan your testing strategy accordingly and perform configuration work only after a planned failover, not during a test failover.

ASR Pricing Note: Azure Site Recovery is free for the first 31 days per replicated VM — a window specifically intended to support migrations. After that, a per-instance fee applies. Factor this into your migration timeline.

Network Security Groups (NSGs) were used to restrict access to the servers, and password and lockout policies were configured carefully — essential when servers are exposed directly to the internet over RDP.

Go-Live Day

On cutover day, the team worked on-site to reconfigure all client workstations to point to the new Azure-hosted servers and verified that each user could log in successfully. The transition was largely smooth — with one notable exception.

Lesson 5: Never Underestimate Printing

The client’s previous environment used a Citrix-specific mechanism to connect users to an on-premises multifunction printer/scanner. With Citrix gone, the team had to fall back to RDP printer redirection — projecting the local printer from each workstation into the RDP session.

Printing is consistently one of the most overlooked aspects of remote desktop and cloud migrations. Citrix and RDS handle printer mapping differently, and edge cases — particularly for multifunction devices used for scanning — can require significant troubleshooting. Audit printing and scanning workflows explicitly before migration day.

Lesson 6: Undocumented Configurations Will Bite You

The multifunction device also scanned documents and sent them via FTP to a watch folder on the server. The FTP password was unknown — to the client, to the incoming IT team, and apparently to the outgoing IT provider as well. The configuration had to be rebuilt from scratch.

This is a universal migration truth: legacy environments almost always contain undocumented integrations, credentials, and services. Budget time during discovery to map every inbound and outbound network dependency, scheduled task, and third-party integration. When in doubt, run a network capture to see what is actually talking to what.

Post-Migration: Operations and Cost Optimisation

After the migration, the environment settled into production with positive results. For some users, login times on the RDS host dropped from over 20 minutes to around 10 seconds — largely attributed to the move from older spinning disk storage to Azure premium SSD and improved network conditions.

Several operational decisions were made to manage cost and resilience:

• Disk sizing: ASR migrates VMs with managed disks sized to match the source VM’s disk sizes. These were found to be larger than necessary, resulting in higher-than-expected costs. Azure allows disks to be increased but not decreased in size. The workaround was to attach new, smaller managed disks and copy data across. When using ASR, review disk sizes post-migration and right-size immediately.
• Disk caching: ASR sets host caching to None by default on migrated disks. Microsoft’s recommendation for data disks on premium SSD is to enable Read caching for improved performance. This setting should be reviewed after migration.
• Backup: Azure Backup was configured to take daily VM snapshots, with hourly transaction log backups for SQL Server, retained for 30 days. Backups are stored across both Australian Azure regions to provide resilience against a regional outage.
• Automated shutdown: Azure Automation runbooks were used to shut down VMs at 9 p.m. and restart them at 5 a.m. local time each day — a simple and effective way to eliminate compute costs during off-hours for a business with predictable working hours.
• MFA for RDP: Duo Security’s MFA solution was layered onto RDP access to the primary server, leveraging the users’ existing familiarity with MFA from the LOB application.
• DNS names over IP addresses: Public IP addresses in Azure are dynamic by default and can change. The team used Azure DNS names mapped to the public IPs to avoid hard-coded IP dependencies in client configurations.

Next Steps

With the migration stable, the team began planning further improvements: moving from pay-as-you-go compute to Reserved Instances for cost reduction on predictable workloads; implementing Mobile Application Management (MAM) policies via Microsoft 365 E3 (an upgrade from Office 365 Business Premium) to protect data on personal mobile devices; and upgrading all workstations to Windows 10 Enterprise to unlock additional security features.

Summary of Lessons

1. Azure Migrate is a starting point, not a migration plan. Use it for sizing and cost estimation, but design the target architecture independently.
2. Reconsider your identity model. Don’t assume the existing directory structure should be replicated into Azure. Evaluate what the workloads actually require.
3. Own the migration execution. Don’t delegate critical migration work to a third party without clear accountability and checkpoints.
4. Investigate before you reinstall. In ASR especially, reinstalling agents can cause new problems. Check logs and error codes first.
5. Audit printing and scanning workflows early. They are frequently overlooked and almost always more complex than expected in RDS or cloud environments.
6. Document everything — and assume nothing is documented. Treat undocumented legacy configurations as a certainty, not a possibility.