Recently google Announcement New serverless Database Migration Service (DMS) In preview. This service supports migrating self-hosted MySQL databases on-premises or in the cloud, as well as managed databases from other clouds to Cloud SQL for MySQL.

New serverless services for database migration are aimed at enterprises migrating to Google Cloud Platform (GCP) managed database services Cloud SQL Or Google computing engine Seamlessly. In addition, according to a post on the announcement blog, customers using this service will benefit from:

Migration using DMS keeps data replication from the source database to the destination without any manual steps, minimizing downtime.
DMS uses the database’s native replication capabilities to maximize fidelity and reliability for a reliable and complete migration.
It’s serverless and secure because you don’t have to provision or manage migration-specific resources or monitor them to keep everything running smoothly.

In addition to Google, Microsoft Azure and AWS also offer database migration services. Azure for customers Azure managed SQL instance service. This allows customers to move their on-premises applications to the cloud with minimal application and database changes. AWS DMS It enables migration from Oracle to Oracle and heterogeneous migration between different database platforms such as Oracle to Amazon RDS for Oracle, MySQL to Amazon Aurora, MySQL to Amazon RDS for MySQL, and Microsoft SQL Server to Amazon RDS for SQL Server.

The impact of public cloud on retail banking is already clear. As a mainstream technology, cloud enables top initiatives such as digital, mobile, and customer analytics. In the corporate banking segment, the pace of cloud adoption and migration has been slower. Top among the forces impeding legacy transformation and the move to the cloud: security and compliance concerns.

Today, corporate banking’s approach to innovative technologies and cloud computing is changing. While on-premises may remain the preferred location for many applications in the near term, the business case for evaluating and making the move to cloud is increasingly clear. Corporate banks are looking to the cloud for agility, innovation, ways to free up budget and move away from capital expenditures, and to keep pace with clients’ expectations for digital engagement.

Findings from Celent’s inaugural Corporate Banking Public Cloud Survey highlight banks’ ambitions and strategies for public cloud adoption for their critical corporate and transaction banking solutions. The results reveal the changing approach that corporate banks are taking toward cloud—and the trends that are likely to continue.

Driving corporate banks’ cloud migrations
Though earlier discussions about the move to the cloud may have been anchored in the possibility of cost savings, many drivers are behind the current interest. Business benefits are clear for both the IT and business divisions of a financial institution (FI). The top drivers are increased agility, which aids in the acceleration of development and innovation, and the ability to spend a greater percentage of the IT budget on innovation.

Additional drivers (each cited by 50% of respondents) include the flexibility provided by moving away from CapEx to OpEx; improved customer experience; improved compliance, compared to in-house managed systems; and an improved ability to partner with the fintech ecosystem. Over the past year, COVID-19 provided an additional impetus, emphasizing the need to enhance client engagement and the overall customer experience; half of survey respondents indicate plans to move more workloads into public cloud infrastructure in response to the coronavirus pandemic.

Moving beyond barriers
Two well-known concerns—security and compliance—were cited by many respondents (63% each) as practical barriers to implementing cloud initiatives. Yet perceptions around security are encouraging: 90% disagreed with the statement that “cloud technologies are not secure enough for bank workloads” and half believe that cloud can contribute to improved cybersecurity.

Other concerns, perhaps discussed less commonly, are also seen as practical barriers to implementing effective public cloud migration initiatives. These include the lack of internal expertise, lack of internal alignment on the

best path forward (caused by risk issues, operational impacts, and changing roles, including within the IT department), and technology infrastructure that’s not yet cloud-ready.

To evaluate how to move forward appropriately, collaborative decisions provide significant value. Clearly, caution is justified when making decisions about technology architecture—particularly when client-facing apps and sensitive financial details are involved. IT groups frequently initiate discussions about enterprise architecture strategy, but plans are often made collaboratively, with input from enterprise architects, line of business (LoB) technology teams, and LoB product managers. At some FIs, however, decisions are left to the CTO/CIO or the IT group.

State of the strategy
Corporate banks tend to be conservative about their approach to public cloud migration. Only 20% (compared to 40% of retail banks) will embark on a broad migration to the cloud. Instead, in corporate banking, non-client facing systems will migrate to the cloud selectively, as reported by 70%; core transaction platforms and customer data will remain on-premise (running in the FI’s data center). Though these systems may remain on-prem in the near term, most banks are (or will be) operating in hybrid multi-cloud deployment environments, using a mix of on-premise, private cloud (infrastructure provisioned for exclusive use by a single organization, comprising multiple consumers or business units) and public cloud (on-demand delivery of compute power, database storage, applications, and other IT resources via the internet with pay-as-you-go pricing) services, with orchestration across platforms.

As all banks anticipate that their architecture will evolve, three out of five respondents feel that their enterprise-wide cloud strategy is articulated clearly. A minority, one in five, report that each line of business is pursuing a cloud strategy independently. Most corporate banks (80%) are working with vendor partners to support their cloud plans. Nearly 90% are using a third-party firm to assist with strategy implementation or ongoing cloud management. Banks often select an IT services firm that already knows the FI’s on-prem technology architecture and software solutions; this specialist knowledge can prove advantageous when helping a bank migrate its solutions to the cloud.

Among the top technologies that data-driven banks are embracing (currently running in or planning to migrate to a public cloud within the coming two years) are:

artificial intelligence/machine learning (AI/ML), reported by 50%,
data lake/data warehouse technologies, reported by 50%, and
robotic process automation (RPA), reported by 40%.
At present, API management platforms and blockchain/distributed ledger technology (DLT) remain on corporate banks’ current infrastructures.

When corporate banks focus on core or critical services (e.g., payments and cash management), a cloud-native/cloud-ready strategy for new software procurement is prevalent, as reported by 60%. Others are agnostic regarding the software deployment method.

Migration considerations
Corporate banks that are evaluating their cloud migration plans should keep three main considerations in mind:

1. The application: Evaluate which applications are most appropriate for your selected cloud environment and architecture.

2. The use case: Determine which use cases are most pressing and best suited to the FI’s cloud migration.

3. The current state: Create cloud strategies for elements of the IT stack that are likely to be successful. These can provide experience to support the more complicated migration initiatives, such as applications that may prove more challenging to get to a cloud-enabled state.

The trend toward cloud is clear for corporate banks. The move will happen stepwise. And when it does, banks will be able to tap into the innovation and agility provided by hybrid, multi-cloud environments.

Microsoft is to acquire Movere, a SaaS platform which increases visibility on IT environments, the companies have announced.

Movere – whom industry watchers may remember until last year as Unified Logic – aims to ‘capture, integrate and analyse the data [companies] need to make smart decisions about their IT environment’, as the company puts it.

The company’s dashboard organically scans global environments at a highest rate of 1,000 servers per hour and focuses across multiple parts of the cloud migration journey, as well as cybersecurity.

Movere has been a partner of Microsoft for more than 10 years and will join the Azure team as part of Azure Migrate, according to a Microsoft blog post.

“We’re committed to providing our customers with a comprehensive experience for migrating existing applications and infrastructure to Azure, which include the right tools, processes, and programs,” wrote Jeremy Winter, partner director for Azure management. “As part of that ongoing investment, we’re excited to welcome the leadership, talent, technology, and deep expertise Movere has built in enabling customers’ journey to the cloud over the last 11 years.”

For Kristin Ireland, CEO of Movere, the acquisition was a time of reflection on the company’s journey to date.

“On our journey to cloud, we made mistakes that cost us valuable time and resources that we didn’t have,” Ireland wrote. “As we spread our wings in the cloud, we realised the cloud was the embodiment of Movere – the unleashing of business potential through migration – we knew we had to be part of that journey for as many customers as we could.

“We passionately believe the cloud journey is what opens the door to market disrupting ideas and opportunities; to be part of that journey with customers and partners is a privilege,” added Ireland. “Thank you to our partners and customers for allowing us to be part of that journey thus far; we are so excited to continue to be faster and better for you as part of the Microsoft Azure team.”

The move represents the first cloudy acquisition of 2019 for Microsoft, aside from investing in big data analytics platform Databricks back in February. This year has been relatively quiet thus far on the acquisition front from the big two; Amazon Web Services (AWS) acquired CloudEndure for a reported $250 million at the start of this year, with undisclosed offers for TSO Logic and E8 Storage since.

Google Cloud, meanwhile, has made more of a statement around its enterprise ambitions with three acquisitions. The company bought business intelligence platform Looker for an all-cash $2.6bn transaction in June, alongside deals for Alooma and Elastifile in February and July respectively.

Why the Globe and Mail Bet on AWS

Like most legacy media organisations, Canada’s Globe and Mail spent years wrestling with the transition from print to digital revenue. The paper ultimately settled on a clear strategic direction: grow digital subscriptions and deepen reader engagement, with Amazon Web Services (AWS) as the core technological foundation.

The AWS migration began several years before this reporting (circa 2019) and was driven largely by the paper’s desire to exploit AI and machine learning capabilities at scale — capabilities that were difficult or cost-prohibitive to run on-premises.

AWS Services in the Editorial Workflow

The Globe and Mail adopted a suite of managed AWS AI services to automate and enrich editorial processes:

• Amazon SageMaker — building, training, and deploying custom machine learning models.
• Amazon Comprehend — natural language processing for topic extraction and content classification.
• Amazon Rekognition — image analysis for photo tagging and content moderation.
• Amazon Textract — extracting structured data from documents.

These services feed into automated workflows that tag and categorise content, match articles to reader interests, and reduce manual editorial overhead.

Sophi: The Globe’s Custom Predictive Analytics Platform

The most strategically significant piece of the Globe’s AWS deployment is Sophi, a recommendation engine and predictive analytics platform built in-house and hosted on AWS. Sophi uses machine learning to forecast how much reader interest a story is likely to attract after publication.

That predictive capability directly informs two high-stakes editorial decisions:

1. Paywall placement — which articles should sit behind the subscription wall and which should remain free to maximise reach and conversion.
2. Promotional effort — how much push, newsletter placement, or social promotion a given story deserves.

The Globe has also begun commercialising Sophi, licensing it to other news organisations — following a model similar to the one that inspired it (see Arc Publishing below).

Arc Publishing: Cloud-Native CMS as a Service

The vast majority of the Globe and Mail’s technology footprint now runs on AWS, including its content management system. The paper was the first launch partner for Arc Publishing, the CMS originally developed by the Washington Post for its own newsroom. The Post subsequently began licensing Arc to other news organisations; the platform is hosted through AWS.

Globe and Mail CTO Greg Doufas acknowledged the partnership carried risk at the outset — adopting a CMS that was still being productised by a direct editorial peer. In practice, Arc proved to be a major improvement over the paper’s previous custom-built CMS, delivering the scalability and reliability a modern digital newsroom requires.

Moving from Dashboards to Raw Data

Doufas joined the Globe and Mail through its data science and analytics team before becoming CTO. He now leads a team of roughly 120 people — approximately half developers, UX designers, and data scientists.

When he arrived, the Globe relied on off-the-shelf web analytics products from vendors such as Google and Adobe. The core problem was access to raw data:

“You’d put the tags on [content], and it would tell you as much as you wanted to know about traffic and patterns and traditional web metrics. But everything was just a report. I couldn’t get to the raw data. I couldn’t imagine doing my job here and evolving the business without manipulating raw data. What were my data scientists going to do? Use dashboards and reports?”

— Greg Doufas, CTO, Globe and Mail

The AWS migration gave the Globe’s data science team direct access to event-level data they could query, model, and experiment with — a prerequisite for building platforms like Sophi.

Audience Understanding as Competitive Advantage

Doufas frames the Globe’s analytical capability in explicitly competitive terms:

“Our intimate and scientific understanding of our audience and the content we create is our competitive advantage. No matter how gorgeous the design is … we will leave it on the cutting floor if it doesn’t perform.”

— Greg Doufas, CTO, Globe and Mail

Custom audience research conducted by the paper found that speed, performance, trust, and credibility were the top drivers of reader loyalty — and that page load speed is tightly coupled with perceptions of trustworthiness. Migrating to a scalable cloud infrastructure directly improved the reader experience on both dimensions.

Multi-Cloud Pragmatism

Despite AWS being the dominant provider, the Globe maintains a deliberately multi-cloud posture. Doufas put it plainly:

“Any CTO worth their salt will want to hedge their bets. We will always have a bit of a toe in the water with other [cloud providers].”

— Greg Doufas, CTO, Globe and Mail

He also noted that concentrating spend with a single provider can unlock volume-based pricing incentives — a practical consideration for organisations running AI workloads at scale.

Key Lessons for Media and Publishing DevOps Teams

• Raw data access matters more than dashboards. Managed analytics tools are useful for reporting, but building ML-driven products requires direct access to event-level data streams.
• Managed AI services lower the barrier to ML adoption. Services like SageMaker, Comprehend, and Rekognition let a mid-sized editorial engineering team operate at a level of ML sophistication that would otherwise require a much larger infrastructure team.
• Shared-platform CMS can pay off. Adopting a purpose-built publishing CMS (Arc) developed by a peer organisation reduced technical debt and accelerated feature delivery.
• Performance is a product decision. Page load speed and reliability are not purely infrastructure concerns — they directly influence audience loyalty and, in a subscription model, revenue.
• Commercialising internal tools creates new revenue streams. Both the Washington Post (Arc) and the Globe and Mail (Sophi) turned internal platforms into licensable products, offsetting development costs.

Background: Kubernetes Authentication Has Come a Long Way

Since Kubernetes 1.0, authentication and role-based access control (RBAC) have matured considerably. However, one area remained stuck in the pre-1.0 era as of mid-2019: the management of service account access tokens that secure connections between Kubernetes pods and the Kubernetes API server.

These legacy tokens were long-lived, lacked automatic rotation, had no expiration enforcement, and carried no audience binding — meaning a token issued for the API server could theoretically be presented to any other service. The risks are largely ones of mismanagement and blast radius rather than a fundamental cryptographic flaw, but at scale those risks add up quickly.

What Workload Identity Revealed About the Problem

In mid-2019, Google released Workload Identity for Google Kubernetes Engine (GKE), positioning it as the recommended way to authenticate containerized GKE application workloads against Google Cloud Platform (GCP) services. Workload Identity uses the bounded, expiring service account tokens introduced in beta with Kubernetes 1.12 to create a cleaner authentication chain between GKE pods and GCP APIs.

The practical benefits are significant:

• No manual secret management: Users no longer need to create, distribute, or rotate Google Cloud IAM service account keys themselves.
• Automatic token rotation: Workload Identity handles credential rotation transparently.
• Short-lived, audience-bound tokens: Tokens expire automatically and are scoped to specific intended audiences, limiting the blast radius of any credential leak.
• Reduced dependency on third-party secret stores: Teams relying on tools like HashiCorp Vault purely for secrets rotation and audience isolation can reduce that overhead.

Josh Koenig, head of product at Pantheon Platform — a web operations platform hosting more than 200,000 Drupal and WordPress sites — described the motivation directly:

“Without this, you end up having to manage a bunch of secrets and access [controls] yourself, which creates lots of opportunities for human error, which has actually bitten us in the past.”

Josh Koenig, Head of Product, Pantheon Platform

Koenig described a specific incident in which a misconfigured development cluster could have exposed an SSL certificate. Pantheon’s team caught the mistake and re-provisioned the cluster, but the near-miss illustrated the fragility of manual credential management. Pantheon used HashiCorp Vault for production workloads, but found its overhead too heavy for development environments — a gap that Workload Identity could close.

Kubernetes Authentication Within Clusters: The Lagging Half

Workload Identity specifically improves authentication between GKE pods and external GCP services. Communications that cross the cluster boundary to cloud-managed APIs are higher-value targets for attackers and therefore benefit most immediately from stronger token semantics.

Intra-cluster pod-to-API-server authentication is a separate problem. The Kubernetes SIG-Auth working group has been developing an analogous improvement for that path: Bound Service Account Token Volumes. When complete, this feature would bring the same automatic rotation, expiration, and audience-binding properties that Workload Identity relies on into every Kubernetes environment — not just GKE.

Mike Danese, a Google software engineer and chair of Kubernetes SIG-Auth at the time, explained the security rationale:

“Our legacy tokens were only meant for use against the Kubernetes API Server, and using those tokens against something like Vault or Google poses some potential escalations or security risks. We’ll push on [API Server authentication tokens] a little bit because we think it improves the default security posture of Kubernetes open source.”

Mike Danese, Chair of Kubernetes SIG-Auth (as of 2019)

The Migration Snag: Bound Service Account Token Volumes

Bound Service Account Token Volumes entered alpha in Kubernetes 1.13 (released December 2018). The core problem the feature solves is that legacy service account tokens are stored as Kubernetes Secrets mounted into pods. The new token format requires a distinct, purpose-built projected volume type — the ServiceAccountToken projected volume source — rather than the legacy Secret-backed approach.

That volume type difference is where the migration headache originates. Early adopters encountered several compatibility issues:

• File permission conflicts: SIG-Auth took a strict stance on file permissions for the new token volumes, which broke some workloads that relied on legacy permission assumptions.
• Pod Security Policy interactions: Existing PSP configurations that permitted legacy token volumes did not automatically permit the new projected volume type, requiring policy updates across clusters.
• Audience binding requirements: Some tooling that consumed service account tokens for non-API-server purposes (e.g., Vault authentication, custom webhooks) needed updates to present the correct audience claim.

Danese acknowledged the tension between correctness and backward compatibility:

“We could soften our stance on some of the improvements to break legacy clients in fewer ways — for example, we’ve taken a hard stance on file permissions, which disrupted some legacy clients… We have some subtle interaction with other security features like Pod Security Policy that we could potentially pave over, by making changes or allowances in Pod Security Policies that would allow old Pod Security Policies to use the new tokens instead of the legacy tokens.”

Mike Danese, Kubernetes SIG-Auth Chair

Beta Delayed Beyond Kubernetes 1.15 and 1.16

As of the time of this reporting (July 2019), the Bound Service Account Token Volumes feature had not reached beta status in Kubernetes 1.15 (released June 2019) and was not expected to reach beta in Kubernetes 1.16 (due September 2019). Danese confirmed this directly. The impact on GKE users of the eventual migration was also still undetermined at the time.

Chris Riley, DevOps delivery director at CPrime Inc., framed what is at stake if the upgrade is deferred too long:

“The issues that are discussed as the abilities of Workload Identity — to reduce blast radius, require the refresh of tokens, enforce a short time to live and bind them to a single pod — would be the potential impacts for current Kubernetes users” if the tokens aren’t upgraded eventually.

Chris Riley, DevOps Delivery Director, CPrime Inc.

What This Means for Cluster Operators

For teams running Kubernetes in 2019 and evaluating their authentication posture, the practical takeaways from this situation are:

1. Audit your service account token usage. Understand which workloads use legacy auto-mounted service account tokens and for what purposes. Any token being presented to a non-Kubernetes endpoint (Vault, cloud APIs, webhooks) warrants closer scrutiny.
2. Treat manual secret management as a risk. As Pantheon’s experience shows, manually managed credentials in development environments can cause real incidents. Where Workload Identity or equivalent managed authentication is available, prefer it.
3. Watch Pod Security Policy configurations. The token volume migration will require PSP updates. Teams with complex PSP configurations should track SIG-Auth progress and test in non-production environments ahead of any broader rollout.
4. Consider managed Kubernetes for reduced migration overhead. Riley noted that his consulting clients were increasingly delegating complex migration work to cloud providers precisely because of situations like this. Managed Kubernetes services can absorb migration complexity at the platform level.
5. Follow SIG-Auth KEPs. The Bound Service Account Token Volumes work is tracked through the Kubernetes Enhancement Proposal (KEP) process. Following the relevant KEP is the most reliable way to track beta and GA promotion timelines.

The Broader Signal: Kubernetes Technical Debt Is Real

This episode illustrates a challenge inherent to any project at Kubernetes’ scale and adoption level: improving foundational security primitives requires coordinating migration paths across thousands of distinct deployments, tooling integrations, and organizational policies. The alpha-to-beta delay on Bound Service Account Token Volumes is not a failure — it reflects the project taking backward compatibility seriously. But it does underscore that improvements to core security primitives in mature, widely deployed projects move slowly and require careful operator preparation.

As Riley summarized: “The value of services like Workload Identity is the additional integration these providers are doing into other cloud services, simplifying the adoption and increasing overall reliability of Kubernetes. I expect them to do the hard work and support migration or simple adoption of future technologies.”

Note: This article reflects the state of the Kubernetes project as of July 2019. Bound Service Account Token Volumes subsequently progressed through beta and reached general availability in later Kubernetes releases. Readers should consult the current Kubernetes documentation for up-to-date guidance.

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.