If you have never heard of the VDDK, that is normal. It is a C library, not a product. It is also the component that lets software outside the hypervisor open a VMDK and read blocks out of it. Combined with Changed Block Tracking, it is what makes agentless migration and agentless backup possible at all. Take it away and a large part of the tooling that reads VMware disks from the outside stops being installable.

Plenty of platforms are affected. This post is only about one of them: AWS. If you are running vSphere and you have been telling yourself that the migration project can wait another budget cycle, this is the part where the calculation changes.

What actually broke on the AWS side

AWS Transform MGN, still widely known as AWS Application Migration Service, offers two replication methods for VMware sources.

Agentless snapshot-based replication runs through the MGN vCenter Client, a software bundle you install on a dedicated Linux VM inside your vSphere environment. It discovers your VMs through vCenter, then for each replication run it takes a VMware snapshot, uses CBT to work out which blocks changed, and reads those blocks with the VDDK before shipping them to AWS.

The VDDK is not bundled with the client. It cannot be, because the licence forbids redistribution. You supply it yourself. The AWS documentation is explicit about the version:

You must log in to your Broadcomm account and download VDDK 7.0.3.3 to the VM on which the MGN vCenter Client is installed. VDDK 7.0.3.3 must be used, regardless of the vCenter version used.

The installer takes it as a parameter, --vddk-path, pointing at the tarball on local disk.

That is the whole problem in one line. VDDK 7.0.3.3 is a 7.0 line release. The 7.x downloads were already unreliable before August, and now the entire download tree is gone. As of writing, that documentation page is unchanged and still tells you to go and fetch a file that cannot be fetched. AWS has published nothing about the change: no bulletin, no what’s-new post, no documentation update. So a customer starting a greenfield agentless deployment today follows the runbook, hits a dead link at step four, and has no official guidance telling them why.

Agent-based replication installs the AWS Replication Agent inside the guest OS. It reads blocks through its own kernel-level driver, talks directly to a replication server in your staging subnet, and never touches the VDDK, vCenter or VMware snapshots. Nothing about it changed on 25 August.

Two things follow from that, and they matter more than the headlines suggest.

First, the practical damage on AWS is narrower than on platforms whose only migration path was VDDK-based. AWS’s own FAQ has said for years that agent-based replication is the default recommendation for all use cases, with agentless reserved for the exceptions: security policy that forbids installing agents, or an OS the agent does not support. The supported operating system lists for the two methods are in fact identical, so in practice the exception is almost always the policy one. Broadcom removed AWS’s fallback, not its main road.

Second, “narrower” is not “none”. If you are the organisation whose change board does not allow third-party agents in the guest, or you inherited an estate where nobody has working credentials for a few hundred VMs, agentless was the answer and it is now gone for new installs.

One nuance worth stating plainly because we have not seen AWS confirm it: an existing vCenter Client installation already has the VDDK on disk, and the client auto-updates itself independently of the VDDK. Running replications are not expected to break. But rebuild that VM, move to a new AWS account, or add a second vCenter environment, and you are back at the 404. Treat every existing vCenter Client as a single point of failure you can no longer reprovision.

Four routes to AWS that do not need a download from Broadcom

1. Agent-based MGN, deployed at scale with the MGN connector

The reflex objection to agent-based migration is that somebody has to log into every VM. That was true a few years ago. It is not the current state of the tooling, and this is the single most useful thing to know if the VDDK removal is what pushed you into a decision.

The MGN connector is a Linux VM in your source environment, registered to AWS through a Systems Manager hybrid activation, that pushes the replication agent out to your source servers for you. You give it network reachability to the sources and a set of source credentials in AWS Secrets Manager, and it handles prerequisite validation, installation on both Windows and Linux, and post-install verification. Installation of the connector itself takes a couple of minutes and is a one-time task per source environment. AWS Transform will now generate the IAM roles, the hybrid activation code and the ready-to-run install command for you through its console flow, or hand you a CloudFormation template if you would rather own the IAM yourself.

For the servers the connector cannot reach, the manual install is a single command. On Linux:

wget -O ./aws-replication-installer-init \
  https://aws-application-migration-service-eu-west-1.s3.eu-west-1.amazonaws.com/latest/linux/aws-replication-installer-init

chmod +x aws-replication-installer-init

sudo ./aws-replication-installer-init \
  --region eu-west-1 \
  --user-provided-id vm-prod-app-014 \
  --no-replication \
  --no-prompt

Two flags earn their keep on a large migration. --user-provided-id sets the identifier MGN uses to recognise the server consistently, which is also what AWS Transform keys on when it maps your inventory into wave plans, so set it at install time rather than trying to reconcile later. --no-replication installs without starting the data flow, which lets you pre-stage agents across hundreds of servers and then switch on replication wave by wave instead of saturating your uplink and your MGN quotas on day one.

Validate the installer hash before you push it estate-wide. It is published per region alongside the binary.

What you need in place, and what tends to be the actual project work rather than the agent install:

• Outbound TCP 443 from every source server to the regional MGN endpoint, and TCP 1500 to the replication servers in your staging subnet. PrivateLink over Direct Connect or Site-to-Site VPN if the data must not cross the internet.
• A staging area subnet with routing to S3, since the replication server fetches its own components from there. This is the single most common cause of a replication that installs cleanly and then stalls.
• Root or administrator on each guest. The Linux installer creates an aws-replication user and adds it to sudoers, and fails if it cannot.
• Kernel headers on the Linux guests matching the running kernel.

The compensation for the extra guest-level work is real: continuous block-level replication rather than periodic snapshot shipping, which means a cutover window measured in minutes instead of waiting for a final snapshot to complete, and no VMware snapshots sitting on your production datastores slowing disk performance during the whole migration.

2. The cached tarball, with a caveat you should not skip

If someone in your organisation still has VMware-vix-disklib-7.0.3.3-*.tar.gz on a build host, a backup appliance or an old runbook attachment, it will still work. The installer only wants a path. Checksums for the 7.0 and 8.0 lines are recoverable from cached copies of the portal, so verify what you hold rather than trusting the filename.

The caveat: Broadcom’s own wording to customers is that the VDDK is no longer available for use or download. Not just download. We are not lawyers and this is not legal advice, but if your plan depends on a cached copy of a proprietary library whose vendor has just told customers it is not available for use, that is a question for your legal team before it becomes a question for your auditor. Ask it now, not the week before cutover.

3. Offline export through VM Import/Export

This is the path that needs no VDDK and no agent at all. Export the VM from vSphere as an OVA or a stream-optimised VMDK using vCenter’s own export function or OVF Tool, upload it to S3, and import it as an AMI:

aws ec2 import-image \
  --disk-containers Format=ova,UserBucket="{S3Bucket=my-import-bucket,S3Key=vms/app014.ova}"

You need an IAM service role named vmimport with a trust policy for vmie.amazonaws.com and permissions on the source bucket and on EC2. Supported input formats are OVA, VMDK, VHD, VHDX and raw.

Be honest with yourself about what this path costs before you make it the plan for more than a handful of servers:

• No CBT, so every attempt is a full copy. A failed import is a full re-copy.
• Staging storage for the exports, on-premises and in S3, sized for your largest VMs.
• Real downtime, because you export a powered-off or quiesced VM and there is no delta sync afterwards.
• Genuine limitations. VMs using Raw Device Mapping are not supported, only VMDK disk images. Encrypted volumes are not supported. Dual-boot configurations are not supported. Neither is the VMware SEsparse delta-file format, nor arm64. Machines that got where they are through a physical-to-virtual conversion are not supported. There is a defined supported-OS matrix and older or unusual guests fall outside it.

VM Import/Export is a good tool for a controlled set of appliances and stragglers. It is not a replacement for a replication-based migration of a few hundred workloads, and anyone who tells you otherwise has not tried it at that scale.

4. Stop moving the VM

The uncomfortable observation in a lot of migration assessments is that a meaningful slice of the estate should not be rehosted at all. A file server becomes Amazon FSx or S3 with DataSync doing the copy. A SQL Server or Oracle instance becomes an RDS instance with AWS DMS handling the load and change data capture. An application server that was built by hand in 2016 gets rebuilt from a pipeline, which is faster than debugging why its agent will not install.

None of those paths care about the VDDK, because none of them read the virtual disk. If your agentless plan just died, this is a good moment to re-run the assessment and ask which VMs you were only lifting because lifting looked cheap.

What to do in the next two weeks

1. Inventory what you hold. Search your build hosts, backup appliances and documentation attachments for VDDK tarballs. Checksum them. Treat them as assets with an expiry date, and get the licensing question in front of legal.
2. Check whether you actually have an existing vCenter Client. If yes, freeze it. No rebuilds, no account moves, no second environment, until you have a tested alternative.
3. Test the agent on your hardest 5 percent. Not your easy Linux fleet. The 2012 R2 box nobody logs into, the appliance with a vendor-locked OS, the VM whose kernel headers are missing. Those are the servers that will decide whether agent-based works for you, and you want to know in September, not in March.
4. Exercise the OVA path once, deliberately. Export one real VM, import it, boot it, log in. A fallback you have never run is not a fallback.
5. Put the date on the wall. General support for vSphere 8 ends on 11 October 2027, with technical guidance running to 2029. That is your outer bound, and it is closer than it looks once you subtract assessment, network design, wave planning and testing.

The pattern is the point

Broadcom is reportedly bringing back a refreshed vSphere Standard aimed at smaller estates, discussed in interviews at VMware Explore rather than announced from a stage, with details promised in October. Read alongside the VDDK removal, the two moves are hard to reconcile as a coherent retention strategy. One says come back, the smaller edition is being looked after. The other quietly removes a dependency that the entire third-party exit ecosystem was built on, with no notice and no replacement.

Whatever the intent, the operational conclusion is the same. The technical routes off vSphere are being narrowed, not widened, and they are being narrowed without warning. The VDDK went away on a Tuesday. Nothing says the next dependency will give you more notice.

If you are going to leave, the cost of leaving is lowest while you still have working tooling, a supported hypervisor version, and time to test. That window is not open indefinitely.

Where Cloudar fits

We have done this often enough to know which parts of a VMware to AWS migration are the hard parts, and the disk copy is rarely one of them. The hard parts are the dependency mapping nobody documented, the network translation, the wave sequencing, the servers that resist every automated approach, and the operational handover afterwards. We work through those with AWS Transform and MGN where they fit, and around them where they do not.

If the VDDK removal has just invalidated your migration plan, or if it has made you realise you did not have one, our AWS migration practice is the place to start. We are an AWS Premier Partner and Migration Competency partner based in Belgium, and we would rather assess your estate honestly than sell you a lift-and-shift you will regret.

For the strategic side of the same question, why the timing of your VMware exit matters as much as the mechanics, see Leaving VMware is a question of timing.

All AWS documentation references were verified on 8 September 2026. AWS had published no guidance on the VDDK removal at that point, and the MGN vCenter Client requirements page still instructed customers to download VDDK 7.0.3.3 from Broadcom.

The post Broadcom just removed the VDDK. Here is how you still get from VMware to AWS. appeared first on Cloudar.

When Broadcom closed its acquisition of VMware, everyone in the industry knew something was going to change. Have we already forgotten what happened to Symantec, among others? Broadcom bought Symantec’s enterprise unit in 2019, narrowed it to around 2,000 of the largest accounts (the Global 2000), and raised prices on most of the rest. VMware is the same script on a bigger stage. The only surprise was how fast it came. In short order, perpetual licenses were scrapped, thousands of cloud partners (Cloudar among them) received a termination letter, and a catalogue of over 8,000 SKUs was reduced to two bundles (VMware Cloud Foundation and VMware vSphere Foundation). The shift from per-CPU-socket licensing to per-physical-core licensing also meant that organizations expecting to simply carry on with an existing installation were suddenly facing invoices two to five times higher.

But those cost increases are relative. The real impact only lands on 11 October 2027, when general support for VCF 8 ends. By that date, every VMware customer has to either migrate to VCF 9 at the new (read: higher) prices and under the new model, or be shown the back door and leave the platform behind.

Not deciding is also a decision

Big decisions like this get postponed fast. Or, in the alternative: you do not decide, and you take the hit. I understand the reflex. Migrations are complex. Infrastructure is critical. You do not want to take risks with production environments. And maybe you are thinking Broadcom will course-correct once the pressure builds. I do not want to give you false hope. By now there is plenty of evidence that Broadcom has no intention of changing course. The messaging is consistent, prices have not come down, and contract negotiations follow a tight, inflexible script.

More importantly, the migration window shrinks every month. A phased, carefully prepared migration of enterprise workloads takes two to three years in practice. If you only start evaluating in 2026, you have almost no room for a calm, controlled execution. The result of waiting too long is not that you end up with more options. It is that you are forced to choose between an expensive rushed migration and an extension with Broadcom at prices you do not actually want to pay. Everyone wins, except the end customer.

And if you are going to migrate anyway, why not move to another on-premises hypervisor? It might look like the most logical step. Nutanix, Proxmox, Microsoft Hyper-V: there are alternatives that keep the virtualization layer intact.

My answer is a nuanced one. For certain workloads with strict data-residency requirements or specific latency constraints, on-premises can remain relevant. But for most companies, switching to another hypervisor is only a stopgap. You solve the price increase, but you keep working with the same operational model. You still manage hardware, license renewals, capacity planning, and the staffing overhead that comes with all of it. On top of that, you trade one vendor dependency for another.

Staying on-premises carries a second problem beyond the licensing model. Hardware is becoming a scarce commodity, and so is datacenter floor space. Prices are going through the roof, and supply is no longer guaranteed.

AWS offers something structurally different: the option to move away from the virtualization layer over time. And getting there is no longer a leap of faith. If you want the smallest possible change on day one, Amazon Elastic VMware Service (Amazon EVS) runs VMware Cloud Foundation directly inside an Amazon VPC in your own AWS account, so the same vSphere, vSAN and NSX stack your team already operates lands on AWS without a re-architecture. If you would rather leave the hypervisor behind right away, AWS Transform MGN (formerly AWS Application Migration Service) replicates your virtual machines block by block and cuts them over to Amazon EC2 with minimal downtime, while AWS Transform for VMware automates the unglamorous parts: discovery, dependency mapping, network conversion, and right-sizing the target instances. The two paths trade off differently. Amazon EVS keeps your VMware stack intact, and with it the VMware licensing, but moves it off your own hardware and onto AWS as the fastest possible landing. The MGN route leaves the hypervisor, and the VMware license, behind outright. Either way your teams keep their existing way of working and do not have to relearn everything on day one.

That is the floor, not the ceiling. Once a workload runs on AWS you can modernize it on its own timeline, and only where the business case justifies it: move a self-managed database onto Amazon RDS or Amazon Aurora, lift a tier of servers into containers on Amazon ECS or Amazon EKS, replace a scheduled job with an AWS Lambda function, and reach for managed AI through Amazon Bedrock. None of that is realistic to run well on-premises, or it is simply too expensive to operate yourself. A like-for-like hypervisor swap does not get you here: it can lower the licensing bill, but the operational model and the eventual modernization are left untouched. Moving to AWS is the option where the immediate fix and the longer-term path share one destination.

We have been doing this at Cloudar for 12 years, and a lot of those conversations reveal the same pattern. At some point an organization made a sound technology choice. And today they find that the choice is holding them in a situation they can no longer defend, or no longer want to. VMware was an excellent choice for years. It was stable, well documented, broadly supported. But the lesson of the Broadcom acquisition is that vendor lock-in is not an abstract technical concern. It is a concrete business risk that, sometimes only after ten or fifteen years, shows up as something you simply have no alternative to.

Moving to AWS does not make that problem disappear entirely, of course. Every major cloud provider has its own ecosystem and its own logic. But the nature of the dependency changes fundamentally. In the cloud you pay for what you use, and you can decide workload by workload how and where you run it. The technical architecture of cloud-native services (open standards, open containers, open APIs) lets you switch when you want. That is structurally different from proprietary hypervisor software with a binary licensing logic. It lets you design with a solid exit scenario built in from the start.

Start with insight, then migrate in phases

Migrations rarely fail on the technology. They fail through a lack of preparation, unclear priorities, and too little attention to the human side of the process. The first step every organization should take is insight: which workloads are you running, what are the dependencies, and what is the real cost of your current VMware installation versus the alternatives? Only once that is clear can you make a rational decision. The tooling to get there has matured: AWS Transform for VMware can inventory a vSphere estate and map its dependencies automatically, and AWS Migration Hub tracks the moves once they start. A Migration Readiness Assessment that used to take months is now achievable in a few weeks.

This is where AWS has invested most visibly. AWS Transform, its agentic migration service, puts AI agents on the parts of a migration that used to eat months of consultant time: discovery, dependency mapping, wave planning, and network conversion, with the actual rehost driven through AWS Transform MGN. It is not VMware-only either; the same agents cover Windows and .NET modernization and mainframe workloads. AWS reports discovery that once took a quarter compressing to about a week, and landing-zone networking provisioned up to 70 percent faster. None of that removes the need to start early. It does mean the preparation that scared you off a year or two ago is no longer the bottleneck it was.

AWS can help fund a lot of this work through the Migration Acceleration Program (MAP). The assessment phase produces a workload inventory, a dependency map, and a costed business case, all of which are yours to keep, whichever direction you choose afterwards. For projects with a strong enough case, MAP can also offset a meaningful share of the migration cost itself. A migration partner runs the assessment and unlocks that funding on your behalf, which is the role we play at Cloudar.

The approach we recommend is phased. Start with the most portable workloads on Amazon EC2, which immediately eliminates the VMware license cost, then replatform workload by workload to AWS-native services as the business case justifies it. And in the meantime, put all new VMware deployments on ice. Every new workload you still put on VMware today is a workload you will have to migrate again later.

What I want to leave you with is this. The best migrations are the ones you carry out when you have the time and the space to do them well. You still have that time and space now, but the clock is ticking. As I write this, there are 467 days left until 11 October 2027. That may sound like a lot…

The post Leaving VMware is a question of timing appeared first on Cloudar.

#1 The broadest & deepest

AWS boasts the broadest and deepest capabilities for Windows of any cloud provider, with nearly twice as many Windows Server Instances compared to its closest competitor. It also offers the widest range of cloud services tailored for Microsoft technologies, seamlessly integrated within a cohesive ecosystem. This includes an array of compute, database, application, and deployment services, along with a comprehensive set of management tools, providing a solution for all your business requirements.

#2 Greater reliability & performance

With 77 Availability Zones (AZ) spread across 24 regions, the AWS Cloud guarantees that your workloads remain operational and accessible precisely when you need them. Customers can reduce their unplanned downtime by a whopping 98% by moving their Windows workloads to AWS. AWS delivers double the performance and achieved a 62% reduction in costs in comparison with the next largest cloud provider for a SQL Server workload on an EC2 R5b.8xlarge instance, according to Principled Technologies.

#3 Superior security

AWS offers a staggering 230 security, compliance, and governance services and features, five times more than its closest cloud provider counterpart. AWS also provides encryption across over a hundred distinct AWS services. By leveraging these comprehensive security offerings, customers can effectively safeguard their environments. The AWS Nitro System in EC2 instances offloads virtualization functions to dedicated hardware and software, effectively reducing the potential attack surface and ensuring minimal exposure to vulnerabilities.

#4 Cost optimization

By leveraging AWS for Windows workloads, customers benefit from accelerated growth, increased operational efficiency, and substantial long-term cost savings. According to IDC, customers can reduce their five-year cost of operations by 56% and achieve a 37% reduction in infrastructure costs. This translates to an impressive 442% return on investment (ROI) over a three-year period. Unique pricing models such as Savings Plans offer savings of up to 72% on Amazon EC2 instances, while Amazon EC2 Spot instances enable cost reductions of up to 90% for fault-tolerant workloads.

#5 Smooth migration

AWS has facilitated the seamless migration of millions of enterprises worldwide, including renowned names like Sysco, Hess, Sony DADC, Ancestry, and Expedia. With the time-tested AWS Migration Acceleration Program (MAP) methodology and the extensive expertise offered by AWS partners, customers are able to evaluate, optimize, and seamlessly shift their Windows and SQL Server workloads to AWS with minimal downtime to applications.

#6 Flexible licensing

AWS provides the broadest range of choices in the cloud for utilizing both new and existing Microsoft software licenses. With the purchase of license-included instances in Amazon Elastic Compute Cloud (Amazon EC2) or Amazon Relational Database Service (Amazon RDS), you receive fully compliant SQL Server licenses directly from AWS. You also have the flexibility to bring your existing licenses to AWS using options such as Amazon EC2 Dedicated Hosts, Amazon EC2 Dedicated Instances, or EC2 instances with default tenancy through Microsoft License Mobility via Software Assurance.

Ready to take the next step? Cloudar has unparalleled expertise in maximizing the potential of your Windows workloads on AWS. Get in touch to let us guide your way to higher performance and efficiency.

The post Unsurpassed: 6 reasons to run Microsoft Workloads on AWS appeared first on Cloudar.

#1 Assessing your current environment

The first step in planning a successful cloud migration strategy is to assess your current infrastructure. This involves identifying the applications, data, and infrastructure that are currently in use, as well as the performance and security requirements of each workload. Once you have a clear understanding of your current environment, you can determine which workloads are suitable for migration to the cloud.

#2 Choosing the right cloud provider  

Choosing the right cloud provider is an important decision that will impact the success of your cloud migration strategy. Factors to consider when choosing a cloud provider include pricing, services, security, and compliance. Speaking to different cloud providers and read customer reviews will help you choose the right provider for your business.

#3 Forming a cloud migration strategy

There are different cloud migration strategies that you can use to migrate your workloads to the cloud. These include lift-and-shift, re-platforming, and refactoring. Lift-and-shift involves moving your applications and data to the cloud without making any changes. Re-platforming involves making some changes to your applications to make them compatible with the cloud. Refactoring involves re-architecting your applications to take advantage of cloud-native services. Each strategy has its pros and cons. Choose the one that best suits your business needs.

#4 Planning the migration

Once you have chosen a cloud provider and a migration strategy, the next step is to create a migration plan. This involves setting timelines, allocating resources, and assessing risks. A detailed migration plan will help ensure that the migration process is smooth and minimizes downtime. Involve all stakeholders in the planning process to ensure that everyone is on the same page.

#5 Data migration

Data migration is a critical part of the cloud migration process. There are different data migration methods, including online and offline migration. Online migration means moving data from your on-premises environment to the cloud over the internet. Offline migration means moving data to the cloud using physical storage devices. Factors to consider when selecting a data migration method include data size, security, and downtime.

#6 Testing and validation

Testing and validation are important steps in the cloud migration process. Test your applications for compatibility, functionality, and performance before and after the migration process. This will help ensure that your applications are working correctly and that there are no issues that need to be fixed. Involving end-users in the testing process helps to ensure that the applications are meeting their needs.

#7 Managing the migration

Managing the migration process ensures that everything is running smoothly and minimizes downtime. Monitor the progress of the migration and communicate with stakeholders to keep them informed. Have a plan in place to fix any issues that may arise during the migration process.

#8 Post-migration optimization

Once the migration process is complete, it’s time to take steps to optimize costs, secure your cloud environment, and maintain compliance. This includes optimizing your cloud infrastructure to reduce costs, securing your cloud environment to protect against cyber threats, and ensuring that your cloud environment complies with industry regulations.

Migrating to the cloud can be a complex process, but with careful planning and execution, it can be a success. Reach out if you need support in navigating a smooth and successful cloud migration!

The post 8 steps to executing a successful cloud migration strategy appeared first on Cloudar.

Shared responsibility model 

Security and Compliance falls under the shared responsibility model between AWS and the customer. Under this model, AWS takes on some of the customer’s operational burden by operating, managing and controlling certain system components as well as the physical security of the facilities in which the service operates. Meanwhile the customer is responsible for the guest operating system, other associated application software as well as the configuration of the AWS provided security group firewall. This model helps share the load while providing flexibility and customer control. 

Under the shared responsibility model, AWS is responsible for the security “of the cloud”, protecting the infrastructure including the hardware, software, databases, networking, and facilities that run AWS Cloud services. The customer is charged with security “in the cloud”, and their responsibility will be determined by the AWS Cloud services they select, which impacts the amount of configuration work they must perform. Their remit includes data protection, identity and access management (IAM), OS configuration, network security and encryption.

Top security considerations 

Here are some of the top security challenges to keep in mind when migrating to the cloud:

• Regulatory and compliance requirements: The cloud environment must meet regulatory requirements and compliance requirements. AWS will have their regulatory requirements covered, but under the shared responsibility model the customer must ensure that they meet privacy requirements on their end, especially concerning sensitive information and access. They may also need specialized controls to meet certain industry requirements.
• Visibility and monitoring: Cloud environments like AWS are large and complex, and contain a wide array of settings to monitor. Security teams may struggle to understand what is going on in cloud environments, especially because cloud migrations imply dynamic change. Provisioning and decommissioning cloud assets rapidly and technical complexities can make security difficult to manage. Gaining visibility is key to identifying dark data and handling data privacy. It’s important to employ industry best practices for initial risk assessment, configuration and security, followed by careful monitoring.
• Managing DevOps: The DevOps team includes developers and infrastructure specialists who manage the DevOps pipeline: coding, building, validation and deployment. When migrating to the cloud, they are responsible for integrating security tools and addressing security issues. They also have to protect against threats when workloads and applications go live.
• Governance standards: Governance workflows and alignments need to become more agile in the Cloud, involving a wider variety of stakeholders. Establishing a set of security standards and baselines in collaboration with the governance team is key. A cloud governance committee can ensure cohesion across teams.
• Protecting network traffic: Just like traditional environments, cloud-based environments can be targets for malware, bots and data breaches. It is essential to control data privacy and protect against cyber threats while securely connecting the cloud to on-premises networks. Information security should be employed to maintain network security parameters.

The way forward 

While it’s important to always carefully account for security considerations, it should still be a no-brainer to go ahead and migrate to the cloud. After all, it’s the new normal for enterprise IT operations. Working with a consulting partner like Cloudar, companies can create a migration roadmap suited to their specific organization. This of course includes all the particulars of their industry and configuration needs. Not only will this make cloud migration more efficient and advantageous, it allows companies to benefit from Cloud Best Practices including security. 

As a Premier Consulting partner, Cloudar has a proven track record of migrating applications and infrastructure to the Cloud. Want to know more about how we execute secure migrations from start to finish? Reach out to us today. 

The post Seamless & secure cloud migration: top things to consider appeared first on Cloudar.

#1 Act first, think later

Once you realize what the cloud can do for you, you might feel inclined to jump right in. Act first, think later. Before you know it, you will feel lost in a haphazardly put together collection of tools. Start by identifying your needs and key objectives. Do your research. Get trustworthy advice. Determine which features and functionalities you want to focus on and stick to them, especially in the beginning. This way you will end up with an efficient, effective and well thought out cloud infrastructure with a guaranteed return on investment.

#2 Too much, too soon

AWS offers a plethora of tools and applications. The possibilities are endless. But not everything that is possible, is also necessary. At least not right now. We would strongly suggest you focus on building a manageable cloud environment that meets your current needs first. Over the long term you can expand and finetune your infrastructure with more advanced applications. If you need any help with selecting the right tools for you, Cloudar is happy to lend a hand.

#3 Compliancy anxiety

Getting started with the cloud might be very daunting at first. You want to build a scalable workspace in the cloud, but how are you going to keep it secure and stay compliant? Data safety in the cloud is one of the biggest concerns when you are considering making the jump. Don’t let this overwhelm you into staying away from the cloud altogether. Security is always job zero. So make sure you have a clear overview of which data needs to be stored in the cloud exactly. Consider the best location for each type of data. Then you can work out your strategy on how to ensure the security of your data. You can absolutely stay compliant without any loss of efficiency or speed. With AWS, you have access to compliant and secure cloud infrastructure. So don’t let compliance anxiety stop you from migrating to the cloud.

#4 Lack of legacy

Many business processes are embedded in legacy systems. They are by far the most important systems, and the backbone of an organization. Migrating these systems to the cloud might be the biggest challenge. Processes can’t stop or be interrupted for too long without significant loss of productivity. Map out your essential processes and define the possible cloud solutions for the immediate and the more distant future. While transitioning, or maybe even in the long term, a hybrid cloud structure might be the solution. That way you can start your cloud migration immediately while combining the legacy system and cloud applications. In time, you can gradually move your entire operation to the cloud.

#5 Resistance to change

Implementing new tools is one thing. But if you do this without paying attention to user adoption, it will fall flat. Change is difficult. People are creatures of habit. Accepting new technology is no exception. To maximize your users’ cooperation and acceptance, it’s important for them to contribute and weigh in during the design process. If you involve your colleagues from the very start, they will feel much more invested in the new way of working. Not only that, they will look at each development phase from the specific point of view of their tasks. That way you make sure that no person or task gets overlooked and they will embrace the new way of working.

Have you encountered some of these challenges in your company’s cloud migration? Do you want to get ahead of them? Or do you just want to spar with an official Next Generation AWS Managed Service Provider Partner? Contact us at Cloudar, no strings attached. Let’s talk!

The post Growing pains: 5 Key Challenges of AWS Cloud Migration appeared first on Cloudar.

“We want to cut costs”

Aren’t we all concerned about our bottom line? When we research a new tool or solution, budget will always be one of the main deciding factors. AWS prides itself on reducing operational costs by 51%. Eliminating costs for hardware and maintenance will significantly limit your recurring data storage costs. Is your business prone to high peaks and off-seasons? With cloud-based computing, you can increase your capacity (and the subsequent costs) when you need them and scale back when business is slow. 

“We want to increase our flexibility”

Technology has supercharged the rate at which businesses evolve, so being able to respond swiftly to market changes is integral to running a successful business. Does your software allow you to scale or pivot with minimum friction and maximum flexibility? A smart cloud migration & configuration can help you to boost productivity, enable more efficient data storage, and facilitate collaboration. 

“We want a solution that is safe and secure”

AWS has several high-profile clients who can’t afford to compromise on data safety. And you will benefit from those security needs. Enjoy AWS’s state-of-the-art data security when you do your cloud migration. Have you considered what will happen to your data in case of a natural disaster? A fire or a flood on-premise could be devastating and keep you offline for weeks, if not months. In the Cloud, data is stored and backed up across several data centers. So no matter what happens, you know that all vital information will stay safe and secure.

What is your reason for considering the Cloud? Get in touch for a personalized assessment.

The post 3 Business Drivers for Cloud Migration According to Our Customers appeared first on Cloudar.

MYTH 1: cloud is more expensive than a data center

Yes, if you put the price of a cloud solution next to the price of a data center, the cloud will be more expensive. But you are comparing apples and oranges. Once you take the total cost of ownership into account, you will see that the cloud is cheaper than an on-premise solution. Another major benefit: cloud offers you insights into your end-to-end. Its transparency helps you to optimize your solution and cut unnecessary costs. Finding out the true cost of your on-premise solution can be difficult.

Source: AWS

MYTH 2: the Cloud is not secure

AWS has a couple of very high-profile customers. The company simply can’t afford any security mishaps. How is this good news for you? Easy: every single AWS customer benefits from that need for rigorous safety mechanisms. Of course, your company also has its part to play. Security and compliance are a shared responsibility between AWS and your organization. AWS operates, manages, and controls components, from the host operating system and visualization layer to the physical security of the facilities in which the system operates. Your job is to ensure the security of the guest operating system (including updates and security patches), other associated application software, and the AWS-provided security group firewall. Some services require more responsibility on the client’s side than others. You can choose and integrate your services based on how comfortable you are with your share of responsibility in keeping everything secure. Maximum flexibility, maximum comfort.

MYTH 3: AWS has access to my data

We understand that privacy and full control over your data are important to you. That’s why we provide APIs for you to configure access control permissions for any of the services you develop or deploy in an AWS environment. 

Here are the services we offer to help you access, encrypt, and log data:

• AWS Identity and Access Management
• AWS Organizations
• AWS CloudTrail

As for us? We do not access or use your content for any purpose without your consent. We never use your content or derive information from it for marketing or advertising. Another concern is the storage of data. You choose where and how your data is stored. With the ability to replicate and back up content in multiple AWS regions. Oh, and you also have full control over how your content is secured. We offer strong encryption, and you can manage your own encryption keys. 

MYTH 4: I’ll be stuck with my cloud vendor

It’s true. Choosing a vendor is a commitment, but it offers enormous flexibility in services and solutions. And moving data cloud-to-cloud is a lot easier than moving information between legacy systems.  

Here are three ways our customers find freedom in cloud technology:

• No long-term commitments: customers can adopt cloud tech on their own terms. AWS customers only use the services they find valuable.
• Customer’s choice: our customers are free to use alternatives to proprietary tools, along with a range of ‘as-a-service’ capabilities. They choose how to invest and create their ideal ecosystem.
• Moving into and out of AWS: AWS services are built to support both migrations into and out of AWS, and we provide many tools and documented techniques to make it easy to do both. 

While some say that combining technology stacks offers you the best of both worlds, we believe the opposite. Learning how to get the most out of a single technology stack will give you a major business advantage.

MYTH 5: The Cloud is killing IT jobs

Au contraire. Cloud helps IT professionals to thrive. When companies transition from on-premise services to the cloud, IT administrators don’t automatically lose their jobs. Most of them transition into the role of a trusted advisor and technical solutions facilitator. 

Cloud computing is growing rapidly at around 17% per year. It is projected to become an 800 billion industry by 2025. That kind of growth requires skilled technical professionals. The World Economic Forum estimates that cloud technology will generate 133 million jobs by 2022.

Do you have any other concerns? Would you like to talk about what cloud computing can do for your business? I’d be happy to chat! Contact me today for a free introductory call.

The post Hey, have you heard? 5 common myths about cloud technology appeared first on Cloudar.

One of the key take-aways, is to travel in good company. Good travelling buddies make you strong and resilient in order to overcome roadblocks. They make you persistent. I have had the joy and luck to travel in very good company the past few years.

Today is the day to stop at a Milestone and enjoy the scenery.

At Cloudar, we are glad to announce that we officially have achieved our AWS Migration Competency Delivery partnership.

With this competency, Cloudar has proven to be a reliable partner and expert for Customers to assist and guide them in their Digital Migration journey.

It will get its place besides all of the other AWS competencies we already achieved.

Look at it as climbing a mountain, you have to be well-prepared for it , and well-equipped. But it will still take quite some effort and make you sweat. But when you arrive at your goal, you will see the clear perspective of where you’re going to. New roads reveil.

Today, with this competency, and with strong support of AWS, we are ready to even help our customers even more with reaching their goals and become a trustworthy travel companion in their Digital Migration Journey.

Maybe the travel metaphor seems less relevant in these times of staycations, but it is the journey itself and your next target that counts. It doesn’t always need to be far, just enjoy the road and your next success.

So, I think we arrived at a conclusion : you now know that Cloudar is an AWS Migration delivery partner ready to roll, staycations can be quite enjoyable too, and I also believe we even have got the people, process, tooling triangle covered along the way…

Please allow me to say special thanks to the travel companions that made it happen : AWS & AWS Partner Migration team, Cloudar Teams and especially our Customers ! Thank you.

Please consult the Public Migration Customer cases on our website and reach out.

The post Great News : Cloudar is an official AWS Migration Competency Delivery Partner ! appeared first on Cloudar.

In IT we have learned to embrace change and new technology. We all need to change if we want our businesses to stay relevant, don’t we? But change, and certainly positive change, doesn’t always happen overnight. It is a process in which we will need to make decisions that will define the desired output.

Since systems, including people and organizations, are interconnected, we have to approach change holistically to make it happen. Therefore, processes exist to guide you during the transformation and help you to arrive at the desired state. In our digital transformation journey and in Cloud Migration it’s not different.

Our approach towards Cloud Migration is a tried and true, structured approach, in which we will first prepare ourselves, then acquire the right methodologies and tools to lay solid foundations and from there on, start practicing and building. During this execution phase, we will iteratively ‘Slice and Dice’ your workloads and business capabilities into reasonable and practical actionables, following an agile approach. Practice makes perfect and before you know it, you’re migrating at scale.

In this perspective, the setup of a highly efficient Migration Factory is utterly important. Here we will make use of the technology and tools at hand to facilitate and automate the migration as much as we can. You can for example make use of CloudEndure, which delivers flexible and innovative migration solutions. Cloudendure offers Continuous block-level replication, cross-infrastructure machine conversion, does automated orchestration and this with a minimal footprint.

Once you’re in the AWS cloud, possibilities to improve, optimize and reinvent are numerous.

Business capabilities will be transformed with available Cloud-Native Services and Technology.

Choosing a partner or MSP that guides you and will help you make the right decisions during the journey, is a direction that you should make as early in the process as possible. It’s an important decision, because once you started your Cloud journey, you will start to see opportunities in which a trusted advisor is a valuable resource to ensure you make the right choices.

Do you want to know where you are in your Cloud journey or where to get started ? Contact your partner for an AWS Migration Readiness Assessment or a AWS Well-Architected Review. It’s a small step, but an essential one to keep your business moving forward in a fast-pace world.

The post Slice and Dice your Cloud Migration and Keep Moving appeared first on Cloudar.