devopsy.kinsta.cloud

Tag: data migration

  • Data Mobility: Why it’s a Must and How to Achieve It

    Data Mobility: Why it’s a Must and How to Achieve It

    The workplace has undergone a drastic change, and so has the way companies need to move their data. Wondering how those two points are connected? Let’s dig in.

    It’s clear that remote work is here to stay: Just over a quarter (26%) of U.S. employees are currently working remotely, and a staggering 36.2 million Americans will work remotely by 2025. Naturally, this huge influx of remote (and hybrid) workers has necessitated changes in IT infrastructure. It has changed how people work, engage with their corporate databases and applications and what they expect from their corporate technology infrastructure.

    In the past, companies migrated their data every four or five years when they refreshed their storage infrastructure. CIOs and storage experts now think differently about how data centers are built and optimized. Important questions all companies should consider are: Does it make sense to build out storage capacity ahead of the need? Do we really plan to have our databases and applications hosted on-premises over the next five years? One CIO recently told me, “If you aren’t talking about your future in the cloud, you aren’t paying attention.”

    The Need to Migrate Data More Frequently

    The shift toward a more flexible storage architecture, even in a hybrid cloud environment, has created the need to migrate data much more frequently, fueling the demand for data mobility. Robust data mobility is essential in today’s world: Companies need to securely and efficiently move their data to accommodate a strategy that accommodates both on-premises and cloud; even multiples of these. Data mobility constraints can’t dictate the success of an organization’s digital transformation. Moving data to the best location based on an organization’s goals—whether they’re related to cost, manageability, performance or some other factor—is critical.

    Another critical factor to consider regarding data mobility: The data must always be accessible to the end user, regardless of when or where it’s moving. In the age of remote work, people are working based on their own unique schedules, so data must be accessible at all times.

    In fact, data from Microsoft recently revealed that 30% of its employees choose to work at night. Gone are the days when systems could be offline for data migration during “non-working hours.” Remote work demands continuous data access so employees can stay productive and work at their convenience.

    With this in mind, here are three key steps companies can take to achieve data mobility.

    1. Strategy
    When determining where to store data, consider who will need access to the data, what performance level will be required and what the cost will be for each data storage location. Is everything best contained in a single public cloud? Is a multi-cloud strategy or a hybrid cloud storage environment a better approach? We often talk about data mobility and data migration interchangeably, but not all data migration solutions can continuously move data between storage environments.

    Organizations must also determine how they will move their database and applications to the new environment. If this step isn’t addressed during the strategy stage, it can become an afterthought and create problems down the road.

    2. Deployment
    Once an organization has determined which storage environment best fits its needs, it’s time to move the data from its source to its destination. A single, one-time migration involves moving the data from its current location to a new location and stepping away until the next migration. Data mobility solutions are ideal when data needs to move back and forth, requiring data mobility solutions (e.g., moving from on-premises to a multi-cloud environment).

    During this step, organizations must ask the following questions and plan accordingly to minimize any negative impact: How long will this migration take? How secure is the data in transit from source to destination? How disruptive will the transition be to end users? What will the impact on the organization be? How much manual effort is required?

    Sometimes moving data can make applications sluggish, affecting productivity and resulting in workers overloading the help desk with inquiries about what’s happening. Data migration tools can help organizations tackle deployment efficiently, securely and without disruption to end users (again, continuous data access is vital).

    3. Assessment and cutover
    After the data has arrived at its new destination, it’s time for the cutover process (i.e., running the application in its new location and removing the old storage). Cutover is when problems can arise if everything isn’t mapped correctly. Organizations need protections in place to ensure there is no risk to their operations should something go awry during the process. Additionally, minimizing the impact of this transition for end users is vital, so organizations should also be doing whatever they can to reduce downtime.

    Companies can consider leveraging a data mobility tool that can synchronize in the background without impacting users. So, while users are still working on the old site, new infrastructure can be updated simultaneously, requiring just seconds to minutes of cutover. This time can be planned for off hours so that it’s minimally disruptive and doesn’t require notifying employees.

    The technology landscape is constantly changing, and so are storage vendors’ offerings. Companies need solid data mobility to pivot at a moment’s notice to take advantage of newer, better and more cost-effective capabilities. Data mobility gives companies the flexibility to stay competitive, and data migration tools that allow continuous data access keep workers productive.

  • Database Migration from Microsoft Azure to Snowflake on AWS: Part 1

    Database Migration from Microsoft Azure to Snowflake on AWS: Part 1

    Technological advancements have increased the demand for enhanced infrastructure with quick deployments. Public cloud providers are constantly upgrading their policies and infrastructure to match ever-growing business requirements. This competition gives businesses the ability to choose the cloud provider(s) that best fit specific governance and cost-effectiveness needs.

    In this blog, we discuss migrating databases from SQL Server on Azure VM to Snowflake on AWS. 

    Understanding the Problem

    Microsoft Azure is a cloud computing offering for Microsoft-managed data centers, whereas Snowflake is a cloud-based data warehousing solution that provides software-as-a-service (SaaS) based on various public cloud providers.

    In this scenario, we need to migrate the SQL Server databases to Snowflake. There is also a need for the migrated data to be put in Snowflake with multiple schemas for database names with the data in the precise and correct form. 

    While Azure supports ingestion from various sources and clouds, it did not support direct egress to other cloud providers. Finding a workable solution for moving egress to AWS-based Snowflake was the first challenge. 

    Our Approach to Migration

    According to the Snowflake documentation, Snowflake has a stage feature that could address the above issue. It is, essentially, a path in which the data files that need to be ingested are stored, similar to the concept of SMB Samba mount. Using Snowflake Stage allowed it to load Azure Blob storage, after which Snowflake could read and ingest the data in flat files. The next step was to move data from SQL Server to Azure Blob storage.

    The Migration Process

    The migration process consisted of the following steps: 

    • Replicate the database schema in Snowflake as per Azure SQL database
    • Set up Azure Data Factory pipeline to create parquet snappy format flat files on Blob storage.
      • Use parquet files for data compression and quick data load in Snowflake
    • Create file format in Snowflake
      • Create or replace file format <file_format_name> type = ‘parquet’;
    • Create Stage in Snowflake
      • create or replace stage <Stage_Name>
      • url='<Azure Blob file/folder path>’
      • credentials=(azure_sas_token= <token>)
      • file_format = <file_format_name>;
    • To verify if files are staged
      • list @ <Stage_Name> ;
    • Finally, load data to Snowflake table from Stage 

    (Note that all parquet data is stored in a single column ($1))

    copy into TEST1

    from (select

    $1:CustomerID::varchar,

    $1:NameStyle:name::varchar,

    $1:Title:city.bag::variant,

    $1:FirstName::varchar,

    $1:MiddleName::varchar,

    $1:LastName::varchar,

    $1:Suffix::varchar,

    $1:CompanyName::varchar,

    $1:SalesPerson::varchar,

    $1:EmailAddress::varchar,

    $1:Phone:name::varchar,

    $1:PasswordHash::varchar,

    $1:PasswordSalt::varchar,

    $1:rowguid:name::varchar,

    $1:ModifiedDate::datetime

    from @ <Stage_Name>);

    Let’s break down the details of each step in the process.

    1. Leveraging Azure Data Factory

    Azure’s Data Factory is a GUI-based tool that facilitates an end-to-end ETL solution and provides a step-by-step guide for building the pipeline. It has Source (SQL server), Target (Blob storage) and the necessary settings for tuning the performance of the pipeline. These offerings made it a perfect solution for the customized needs of this migration project—which was to wrangle the data before exporting to Blob storage. This was addressed seamlessly by Data Factory which is covered in detail in the later section of this blog.

    2. Tuning the Performance of Data Factory Pipeline

    The tricky part of this migration was that while the pipeline was easy to build, utilizing its full potential and deriving optimum performance was a challenge.

    There were terabytes of data that needed to be exported to Blob from SQL, which would have taken weeks to transfer without tuning. After adequate POC, it was found that Data Factory could support dynamic range in reading data from the source.

    Let’s say there is a table XYZ that is 800 GB. As per the approach mentioned above, Data Factory is required to move the huge amount of data into Blobs. With the traditional method, the GUI, by default, writes the data to Blob serially which would be slower.

    Now, if we look at the table XYZ with a column “date”, the 800 GB of data can be partitioned into small sets depending on month or year. This would mean that each partition is not directly dependent on other date partitions and can be written in parallel. This will be quicker and more resource-efficient.

    This can be achieved by using the dynamic range filter which can be only applied by writing the select statement rather than selecting the checkbox of the existing tables.

    3. Using Parquet File

    The exported data needed to be stored in a flat file while maintaining integrity and compression. CSV was the first choice but during POC many challenges were faced while writing the file, maintaining the spaces and new line characters which corrupted data. The Data Factory offered the Parquet format of a file that had a great compression rate (75%) and also maintained the integrity of the data. Parquet was optimized to work with complex data in bulk and thus was suitable for this project. With respect to the above figure, it can be seen that  40GB of data was compressed to 11GB.

    4. Integration Runtime

    For the Data Factory to work, it required more compute power which was facilitated in the following ways: 

    • Auto-Resolve Integration Runtime

    As the name suggests, the compute resources were managed and assembled by the Microsoft data centers and the cost was incurred on a per-unit basis. The region of these resources was automatically decided based on availability. This is selected by default when running a Data Factory pipeline.

    • Self-Hosted Integration Runtime

    This runtime uses the resources that already exist. For example, the self-hosted IR allowed downloading a client program on the machine for the resources required and creating a service and coupling it with the Data Factory.    

    4. Setting up the Self-Hosted Integration Runtime

    This was the best available option as the SQL server was already hosted on a standalone Azure VM, which provided the freedom to use the full capacity of resources attached to it. It included the following steps: 

    1. Setting-up Self Hosted IR

    • For Azure Data Factory to work with Azure VM it needed to set up the Azure Data Factory Integration Runtime
      • In Azure Data Factory, select “Manage” and then “Integration Runtimes”
      • Select “+ New”, then “Azure, Self Hosted”, 
      • Next, select “Network Environment -> Self hosted”
      • Next, give a suitable name to the self-hosted IR
      • Once the IR is created, Auth keys will be presented. Copy these keys
    • Now as per the last screen, a link was provided to download Microsoft Integration Runtime
        • Download and install the integration runtime from the Microsoft link
        • Once installed, enter the Auth Key1 value and register “Launch Configuration Manager”
        • When registered, the self-hosted IR will bind with the data factory
        • Now, install the Java Runtime 64 bit as it is required for the self-hosted IR to work. Refer to this manual.

      2. Create Linked Service in Data Factory

    • Proceed to Data Factory 
      • Select “Manage” and then “Linked Services”
      • Select SQL server as type of service and give it a suitable name
      • Now under “Connect via Integration Runtime” select the created self-hosted IR
      • Put in the server name. It is important to note that the server name should be the same name used to connect the SQL server successfully
      • Put in the credentials and test connection

    In the next blog, we shall look at some of the challenges encountered during the migration, cost-saving actions and our approach to data validation.

  • Ten Questions Data Professionals Should Be Asking When Moving to the Cloud

    Ten Questions Data Professionals Should Be Asking When Moving to the Cloud

    You have finally decided to move your data into the cloud. Whether it was the ability to leverage the power of cloud compute, the promise of cost-savings or the scalability and flexibility that a cloud data warehouse can bring, it’s important to have a strategy in place. In order to set yourself up for success, here is a list of questions that will help you organize your data and ensure your data migration efforts provide business value.

    What Is the Outcome I Need to Achieve?

    When you are creating a data migration strategy, you need to have an end goal in mind in order to make the best decisions on technology and approach. Simply getting your data into the cloud won’t be enough to take action on that data. 

    How Many Data Sources Do We Currently Have? 

    Once you have your outcome in mind, take a comprehensive inventory of all your data sources before you begin the migration process. It reduces your risk of discovering halfway through the process that you have no access to a data source–or that you forgot to include it in your migration plan. 

    Who Is the Administrator of Each Data Source? 

    It is likely that you may not have access to every single data source that you are looking to migrate. Make sure to find out who can provide you with access to that data, and fully understand your requests. This person will be able to explain the necessary requirements for that data source and will be your contact to help integrate that source into your migration efforts. 

    What Data Is Most Important to My Key Stakeholders, and What Do They Consider Important in Getting that Data? 

    This question might also be: What are the KPIs that drive the business from the data sources? You’ll need to have a good grasp on the metrics that are used for business-critical KPIs so that you have the right data in the cloud to ultimately be transformed for analysis. For example, a retailer might value click-through-rate on emails as a key indicator of attribution for sales data. In order for them to get that information, they would need to provide data from their email marketing system and their eCommerce platform. Keep stakeholders involved in the success and failure criteria of your project so they can help set you up for success. Identify the system of record for the metrics that each KPI is calculated from. Quite often, more than one system in your organization can have a representation for that key metric, but with different values. Align with the related stakeholders as to which is the system of record in those cases. 

    How Can I Show Business Impact Quickly?

    A proof of concept (PoC) in the cloud is always associated with the desire to show results quickly, as the speed and performance that the cloud brings means that you should be able to move faster, right? Asking yourself what you can do to help the business recognize the value of your project can help you assuage any productivity concerns. To create a quick PoC, start by first identifying a small number of typical use cases to test out. Picking a high-value KPI that is calculated from metrics from well known source systems could be a good candidate for that first iteration.

    What Are My Security Concerns?

    Considering that the cloud can house petabytes of data that enterprise companies collect every day, it is safe to assume that some of that information will be sensitive and confidential. Ask yourself if the data you migrate contains personally identifiable information (PII) and if that information is necessary for the project you are working on. In most cases, PII is not needed for analytics work and therefore, you wouldn’t need to migrate that. You might need to know the brand of a credit card to make a data-driven business decision but perhaps not the actual credit card numbers. 

    Who Has Access to My Data Now that It Is in the Cloud?

    If you are migrating sensitive data into the cloud, these are the security and compliance requirements that come into play. How much data security management you entrust to a cloud provider entirely depends on the needs and requirements of your business. There are several different security models, some of which give you more control, some that hand-off that control to cloud providers—it is important to choose the model that works best for your business. Ensure the vendors you use are SOC II compliant and have all the necessary certifications in place to keep your data safe. Work with your organization’s security group on this. They may have defined an overarching Enterprise Cloud Strategy which can help to provide guidance around the acceptable use of cloud resources for your analytics workloads.

    What Do I Do with My Data Once It’s in My Cloud Data Warehouse? 

    Once your data is in the cloud, what do you plan to do with it? Create a strategy to structure your data in the correct way for your business outcome. Different cloud-built technologies can help structure your data for analytics, prepare your data for machine learning or artificial intelligence projects, or perform data cleansing so you have the most accurate data available. It is important to remember that different cloud data warehouses, data integration tools and data visualization products need to complement one another. Make sure you build your stack for your project to ensure success. 

    How Do I Save Costs in the Cloud? 

    In addition to faster time to value, one of the main reasons companies migrate data to the cloud is to save costs. But, how can you ensure you are saving costs while migrating data? You can take advantage of free trials offered by many purpose-built cloud data tools that allow you to allocate, compute and storage as needed. The beauty of a cloud data warehouse is that you don’t need to provision for future workloads. As your needs grow, you can scale up easily and manage costs effectively. Try to avoid using multiple products that do similar things. This will reduce cost, increase adoption of the products and keep your architecture simple.

    Is My Team Equipped to Handle Cloud Migration?

    Cloud data migration is different than on-prem migration and in such, you and your team will be using technology that you haven’t used in the past. To set your team up for success, inquire about their comfortability using the tools you’ve selected and ensure they have the level of access needed to do their jobs efficiently. If there are gaps in knowledge, you can look to provide the training to help them get up to speed and make onboarding as painless as possible.

    If you answer these ten questions, you will be on the right track to begin your cloud data migration project. Keep your business goals in mind and start small—the flexibility of the cloud allows you to scale your project later if needed.

    — Arawan Gajajiva

  • Tips for Migrating and Managing Data Workloads in the Cloud

    Tips for Migrating and Managing Data Workloads in the Cloud

    Unless you are an alien life form who just beamed down from space, you’ve heard all about the why of moving data workloads to the cloud. The cloud is a more scalable, more flexible, more available and possibly less expensive solution for storing and processing data.

    What is not always obvious is the how of moving data workloads to the cloud. In several key respects, cloud-based data workloads are fundamentally different than those hosted on-premises.

    Understanding those differences is critical for moving data workloads to the cloud effectively. While it’s true that the cloud offers a variety of benefits for hosting data workloads, actually realizing those benefits requires a plan for managing data effectively once it is in the cloud.

    Let’s take a look at what that entails.

    The Special Challenges of Cloud-Based Data Workloads

    Let’s start by identifying the main ways in which cloud-based data workloads differ from those hosted on-premises:

    We could/should add a section here about assessment/planning before the actual migration. We have a bunch of published material on this.

    • Migration: The ways in which you migrate data to the cloud (and migrate it from one location to another within the cloud) are different from those you use on-premises. Not only do the tools typically differ (in the cloud, you’ll usually need to use your cloud vendor’s tools and interfaces for uploading and moving cloud-based data), but the speed and process are usually different, too (in the cloud, you’ll typically have to transfer data over the network, which is slower than some on-premises data transfer techniques). In extreme cases, migrating data over the network into the cloud may simply be unfeasible, which is why AWS Snowmobile is a thing.
    • Availability: In some respects, cloud-based data workloads are more available; in general, the cloud is less likely to fail or become unresponsive than your own data center. That said, the considerations for data availability in the cloud are different than on-premises. For example, DDoS attacks are typically a greater threat to data availability in the cloud. As a result, the strategies (discussed below) for maximizing cloud data availability are also different.
    • Performance: The factors that impact data workload performance in the cloud differ in some respects from those on-premises. In the cloud, it’s not the number of CPU cores or memory in your servers that matters, since these resources easily can be increased. It’s the way you build your data workload architecture and how effectively you avoid bottlenecks that shapes the performance of your workloads.
    • Cost: In an on-premises data processing environment, the lion’s share of your costs are the upfront capital expenditures required to build your infrastructure. In the cloud, your costs are monthly bills based primarily on resource consumption and the types of services you use. This means cost structures and the strategies for optimizing costs are very different for cloud-based data workloads.
    • Security: Cloud security is a discipline unto itself. Depending on which types of services you use in the cloud and how much control you have over the physical infrastructure (typically, you have minimal control), your security strategy for cloud workloads may look very different from the one you use to secure on-premises infrastructure.

    Working Effectively With Cloud-Based Data Workloads

    How do you manage the special challenges that cloud-based data workloads impose? Following are some tips.

    Perform a Migration Assessment

    As noted above, data migration into the cloud is a common pain point. Given this, and the fact that your migration strategy lays the foundation for the ongoing success of your data workload, it’s important to perform a migration assessment before beginning your migration.

    A migration assessment involves determining not only how to get your data into the cloud, but also how you will adapt your data architectures and strategy to fit the cloud. Will you simply lift and shift data into the cloud, keeping the same general architecture in place? Or will you modernize your data workloads by taking advantage of new technologies you didn’t use in your on-premises environment?

    The major cloud vendors offer a suite of tools to help answer these questions:

    Use the Network Effectively

    The network can be the biggest bottleneck in a data pipeline. Given the centrality of networks to the cloud, it’s therefore important to ensure you leverage the network efficiently.

    One way to do that (especially during the data migration stage) is to take a provisioning approach, which involves moving data gradually into the cloud and provisioning cloud infrastructure to fit each specific data workload in a cost-efficient way. This can be more cost-effective than lifting and shifting all of your data into the cloud at once, which can leave you with hefty data migration fees.

    Replicate Cloud Data Intelligently

    One of the best ways to maximize data availability in the cloud is to replicate it across multiple cloud data centers and/or regions. Doing so maximizes the chances of keeping your data available in the event that one cloud data center fails, which is rare but does happen.

    Of course, the more data replication you use in the cloud, the more you will pay, so you need to balance your replication strategy with your budget.

    Used Tiered Storage Effectively

    Most cloud vendors offer different tiers of storage. The default tier is designed for data that needs to be accessed on a frequent basis, but you can save money by choosing tiers designed for infrequently accessed data or archival storage. The price you pay for using lower-cost storage tiers is slower data access time, but in cases where you don’t need to access data quickly or frequently, low-cost tiers can do a lot for your budget.

    Access Control, Access Control, Access Control

    In the cloud, you often have little control over underlying infrastructure or software environments. You can’t harden the host operating system for your cloud servers and the metrics you can feed from a cloud environment into your SIEM are often limited.

    What you can do to help secure most cloud environments, however, is to set strict access controls. Configuring IAM policies may not be most engineers’ idea of a good time, but it’s critical to perform this tedious work to help secure cloud-based data workloads.

    Backup

    When you move data workloads to the cloud, it can be tempting to assume you don’t need to back them up, because the cloud never disappears.

    It’s true, the cloud is very resilient, but that doesn’t eliminate the need for data backups. There is always a chance—however small—that cloud-based data could be lost permanently. You also face the (less uncommon) risk of having your cloud-based data become corrupted or infected with malware—in which case it’s useful to have clean backup copies from which you can restore.

    So, back up your cloud-based data, too. As a best practice, it’s wise to follow a 3-2-1 backup strategy, which entails keeping multiple backups of your data in isolated locations.

    Conclusion

    The cloud is a fundamentally different beast than your on-premises infrastructure. Making the most of cloud-based data requires you to rethink your strategies for data migration, availability, security and more in certain respects. You need not discard everything you know about on-premises data management, but you need to adjust your operations to address the special challenges of the cloud.

    This sponsored article was written on behalf of Unravel.

    — Chris Tozzi

  • How to prepare for a successful data migration

    How to prepare for a successful data migration

    It can be tough to find useful, concrete advice to assist you with an enterprise-level data migration project. There’s an awful lot that can go wrong. Common suggestions about finding the right people, minimizing risk, or employing an automated system that does everything for you, offer limited help.

    What you really need is a step-by-step checklist that you can work through.

    The success or failure of a data migration depends largely on how thoroughly and carefully you prepare for it. If we analyze large migration projects, we invariably find that the successes share many common characteristics. If you’re planning a data migration, these are the questions that you really need to answer:

    What type of data is being migrated?

    Not all data is created equal. There are various different types of data, so you need to be clear about exactly what you want to move.

    • NAS-based – Where network shares are migrated from one system to another.
    • LUN-based – Where the disks (LUNs) are migrated from one place to another, at block level.
    • VM-based – Where the entire virtual hosts are migrated from one hypervisor to another.
    • Application-specific – Where one set of databases or objects, is migrated from one host to another.

    What type of migration is it?

    Where your data is going, can make a big difference to your overall plan. Is this a local migration, within the same data center, a remote migration, shifting data from one center to another, or is it a cloud migration, where you might be moving data from one cloud provider to another?

    What is the current storage environment?

    You need a complete overview of your current storage environment before you move a single file. If you’re using SAN, then think about what hosts, in terms of operating systems and applications, are involved. What are the FC switches and RAIDs? Do you have a clear picture of all the inter-dependencies within the SAN? A deep understanding of the environment and its complexity, gives you a better chance of avoiding disaster.

    How much data is being migrated?

    An accurate estimate of the volume of data that needs to be moved is absolutely vital. You need to account for all the hosts, LUNs, and storage systems. It’s not enough to say how many terabytes of data need to be migrated, you’ll need a picture of how that breaks down before you can determine the time and effort required.

    How much time do you have?

    There’s always a deadline for any project. Your timeframe may ultimately be dictated by the volume of data and the migration rate, but you can only determine that rate with a complete understanding of the data, application, and environment. Can you migrate in a divide-and-conquer manner? The more you know, the easier it is to control operational complexity and reduce costs.

    How active is the data and how much downtime is possible?

    In order to determine whether the migration can be completed on time, or even at all, you need to know how active the data is. How much of an impact on production will be tolerated? Some downtime is inevitable, but it has to be worked out and agreed upon ahead of time. Creating the right strategy in advance, with all the key stakeholders, will dramatically boost your chances of success, and reduce stress levels on the day.

    What’s the right tool for the job?

    This is really going to depend on all of your answers so far. The right way to go about selecting is to draw up a list of evaluation criteria. Think about everything you need and create a list that you can cross-reference against the candidates.

    As an example, for a SAN migration, you might want something that offers the following:

    • A seamless installation with no disruption to the production environment.
    • A clear display for the automatically discovered SAN configuration, complete with identities, status, and I/O statistics for all hosts and LUNs to be migrated (as well as those not to be touched), so the migration operation can be organized correctly and accurately with high confidence.
    • The ability to migrate during non-production hours, or automatically yield to production traffic, with adjustable intensity/throttling.
    • A centralized reporting system that delivers the statistics you need.
    • Data integrity checking of intermediate images before cutover, so issues are flagged early before they can cause problems.
    • Secure wiping of the data disks after the data is successfully migrated out.

    When you’ve drawn up a list, you can apply it, and see how different options compare.

    Who are the right people for the job?

    A successful data migration is going to require some level of expertise. Ideally, you want experienced personnel to handle a process like this, and you may need to look externally to find them. If they can give you the answers you need to address the questions we’ve posed here in this article, then you know they’re qualified for the job.

    About the Author/Wai T. Lam

    CTOWaiLamCirrus

    Wai T. Lam is co-founder and CTO of Cirrus Data Solutions, a developer of Data Migration Server and Data Caching Server for storage area networks (SANs). He was previously CTO and VP of Engineering at FalconStor, a company he co-founded in 2000. There, he was the chief architect, holding 18 of 21 company patents. Wai received the prestigious China national “Top 1000 Technological Leaders” award in 2013.