Azure Cloud Migration and Modernization Services

Belitsoft is a team of Azure migration and modernization experts with a proven track record and portfolio of projects to show for it. We offer comprehensive application modernization services, which include workload analysis, compatibility checks, and the creation of a sound migration strategy. Further, we will take all the necessary steps to ensure your successful transition to Azure cloud. Planning your migration to Azure is an important process as it involves choosing whether to rehost, refactor, rearchitect, or rebuild your applications. A laid-out Azure migration strategy helps put these decisions in perspective. Read on to find our step-by-step guide for the cloud migration process, plus a breakdown of key migration models. An investment in on-premises hosting and data centers can be a waste of money nowadays, because cloud technologies provide significant advantages, such as usage-based pricing and the capacity to easily scale up and down. In addition, your downtime risks will be near-zero in comparison with on-premises infrastructure. Migration to the cloud from the on-premises model requires time, so the earlier you start, the better. Dmitry Baraishuk Chief Innovation Officer at Belitsoft on Forbes.com Cloud Migration Process to Microsoft Azure We would like to share our recommended approach for migrating applications and workloads to Azure. It is based on Microsoft's guidelines and outlines the key steps of the Azure Migration process. 1. Strategize and plan your migration process The first thing you need to do to lay out a sound migration strategy is to identify and organize discussions among the key business stakeholders. They will need to document precise business outcomes expected from the migration process. The team is also required to understand and discover the underlying technical aspects of cloud adoption and factor them into the documented strategy. Next, you will need to come up with a strategic plan that will prioritize your goals and objectives and serve as a practical guide for cloud adoption. It begins with translating strategy into more tangible aspects like choosing which applications and workloads have higher priority for migration. You move on deeper into business and technical elements and document them into a plan used to forecast, budget, and implement your Azure migration strategy. In the end, you'll be able to calculate your total cost of ownership with Azure’s TCO calculator which is a handy tool for planning your savings and expenses for your migration project. 2. Evaluate workloads and prepare for migration After creating the migration plan you will need to assess your environment and categorize all of your servers, virtual machines, and application dependencies. You will need to look at such key components of your infrastructure as: Virtual Networks: Analyze your existing workloads for performance, security, and stability and make sure you match these metrics with equivalent resources in Azure cloud. This way you can have the same experience as with the on-premise data center. Evaluate whether you will need to run your own DNS via Active Directory and which parts of your application will require subnets. Storage Capacity: Select the right Azure storage services to support the required number of operations per second for virtual machines with intensive I/O workloads. You can prioritize usage based on the nature of the data and how often users access it. Rarely accessed (cold data) could be placed in slow storage solutions. Computing resources: Analyze how you can win by migrating to flexible Azure Virtual Machines. With Azure, you are no longer limited by your physical server’s capabilities and can dynamically scale your applications along with shifting performance requirements. Azure Autoscale service allows you to automatically distribute resources based on metrics and keeps you from wasting money on redundant computing power. To make life easier, Azure has created tools to streamline the assessment process: Azure Migrate is Microsoft’s current recommended solution and is an end-to-end tool that you can use to assess and migrate servers, virtual machines, infrastructure, applications, and data to Azure. It can be a bit overwhelming and requires you to transfer your data to Azure’s servers. Microsoft Assessment and Planning (MAP) toolkit can be a lighter solution for people who are just at the start of their cloud migration journey. It needs to be installed and stores data on-premise but is much simpler and gives a great picture of server compatibility with Azure and the required Azure VM sizes. Virtual Machine Readiness Assessment tool Is another great tool that guides the user all the way through the assessment with a series of questions. Besides the questions, it also provides additional information with regard to the question. In the end, it gives you a checklist for moving to the cloud. Create your migration landing zone. As a final step, before you move on to the migration process you need to prepare your Azure environment by creating a landing zone. A landing zone is a collection of cloud services used for hosting, operating, and governing workloads migrated to the cloud. Think of it as a blueprint for your future cloud setup which you can further scale to your requirements. 3. Migrate your applications to Azure Cloud  First of all, you can simply replace some of your applications with SaaS products hosted by Azure. For instance, you can move your email and communication-related workloads to Office 365 (Microsoft 365). Document management solutions can be replaced with Sharepoint. Finally, messaging, voice, and video-shared communications can step over to Microsoft Teams. For other workloads that are irreplaceable and need to be moved to the cloud, we recommend an iterative approach. Luckily, we can take advantage of Azure hybrid cloud solutions so there’s no need for a rapid transition to the cloud. Here are some tips for migrating to Azure: Start with a proof of concept: Choose a few applications that would be easiest to migrate, then conduct data migration testing on your migration plan and document your progress. Identifying any potential issues at an early stage is critical, as it allows you to fine-tune your strategy before proceeding. Collect insights and apply them when you move on to more complex workloads. Top choices for the first move include basic web apps and portals. Advance with more challenging workloads: Use the insights from the previous step to migrate workloads with a high business impact. These are often apps that record business transactions with high processing rates. They also include strongly regulated workloads. Approach most difficult applications last: These are high-value asset applications that support all business operations. They are usually not easily replaced or modernized, so they require a special approach, or in most cases - complete redesign and development. 4. Optimize performance in Azure cloud After you have successfully migrated your solutions to Azure, the next step is to look for ways to optimize their performance in the cloud. This includes revisions of the app’s design, tweaking chosen Azure services, configuring infrastructure, and managing subscription costs. This step also includes possible modifications when after you’ve rehosted your application, you decide to refactor and make it more compatible with the cloud. You may even want to completely rearchitect the solution with Azure cloud services. Besides this, some vital optimizations include: Monitoring resource usage and performance with tools like Azure Monitor and Azure Traffic Manager and providing an appropriate response to critical issues. Data protection using measures such as disaster recovery, encryption, and data back-ups. Maintaining high security standards by applying centralized security policies, eliminating exposure to threats with antivirus and malware protection, and responding to attacks using event management. Azure migration strategies The strategies for migrating to the Azure cloud depend on how much you are willing to modernize your applications. You can choose to rehost, refactor, rearchitect, or rebuild apps based on your business needs and goals. 1. Rehost or Lift and Shift strategy Rehosting means moving applications from on-premise to the cloud without any code or architecture design changes. This type of migration fits apps that need to be quickly moved to the cloud, as well as legacy software that supports key business operations. Choose this method if you don’t have much time to modernize your workload and plan on making the big changes after moving to the cloud. Advantages: Speedy migration with no risk of bugs and breakdown issues. Disadvantages: Azure cloud service usage may be limited by compatibility issues. 2. Refactor or repackaging strategy During refactoring, slight changes are made to the application so that it becomes more compatible with cloud infrastructure. This can be done if you want to avoid maintenance challenges and would like to take advantage of services like Azure SQL Managed Instance, Azure App Service, or Azure Kubernetes Service. Advantages: It’s a lot faster and easier than a complete redesign of architecture, allows to improve the application’s performance in the cloud, and to take advantage of advanced DevOps automation tools. Disadvantages: Less efficient than moving to improved design patterns like the transition to microservices from monolith architecture. 3. Rearchitect strategy Some legacy software may not be compatible with the Azure cloud environment. In this case, the application needs a complete redesign to a cloud-native architecture. It often involves migrating to microservices from the monolith and moving relational and nonrelational databases to a managed cloud storage solution. Advantages: Applications leverage the full power of Azure cloud with high performance, scalability, and flexibility. Disadvantages: Migrating may be tricky and pose challenges, including issues in the early stages like breakdowns and service disruptions. 4. Rebuild strategy The rebuild strategy takes things even further and involves taking apart the old application and developing a new one from scratch using Azure Platform as a service (PaaS) services. It allows taking advantage of cloud-native technologies like Azure Containers, Functions and Logic Apps to create the application layer and Azure SQL Database for the data tier. A cloud-native approach gives you complete freedom to use Azure’s extensive catalog of products to optimize your application’s performance. Advantages: Allows for business innovation by leveraging AI, blockchain, and IoT technologies. Disadvantages: A fully cloud-native approach may pose some limitations in features and functionality as compared to custom-built applications. Each modernization approach has pros and cons as well as different costs, risks and time frames. That is the essence of the risk-return principle, and you have to balance between less effort and risks but more value and outputs. The challenge is that as a business owner, especially without tech expertise, you don't know how to modernize legacy applications. Who's creating a modernization plan? Who's executing this plan? How do you find staff with the necessary experience or choose the right external partner? How much does legacy software modernization cost? Conducting business and technical audits helps you find your modernization path. Dmitry Baraishuk Chief Innovation Officer at Belitsoft on Forbes.com Professional support for your Azure migration Every migration process is unique and requires a personal approach. It is never a one-way street and there are a lot of nuances and challenges on the path to cloud adoption. Often, having an experienced migration partner can seriously simplify and accelerate your Azure cloud migration journey.

What is HIPAA-compliant Database?  A database is an organized collection of structured information controlled by a database management system. To be HIPAA-compliant, the database must follow administrative, physical, and technical safeguards of the HIPAA Security Rule. Often it means limiting access to PHI, as well as safely processing, transmitting, receiving, and encrypting data, plus having a proactively breach mitigation strategy. Administrative, physical, and technical safeguards of the HIPAA Security Rule HIPAA Rules for Database Security If your database contains even a part of PHI, it is covered by the HIPAA Act of 1996 and can attract the attention of auditors. PHI is the information containing any identifiers that link an individual to their health status, the healthcare services they have received, or their payment for healthcare services. The HIPAA Security Rule (the part of HIPAA Act) specifically focuses on protecting electronic PHI. Technical safeguards (the part of HIPAA Security Rule) contain requirements for creating a HIPAA-compliant database. Centers for Medicare & Medicaid Services (CMS) covers HIPAA Technical Safeguards for database security in their guidance. The first question that can arise is whether you should use any specific database management system to address the requirements? The answer is absolutely no. The Security Rule is based on the concept of technology neutrality. Therefore, no specific requirements for types of technology are identified. Businesses can determine themselves which technologies are reasonable and appropriate to use. There are many technical security tools, products, and solutions that a company may select. However, the guidance warns that despite the fact that some solutions may be costly, it can’t be the cause of not implementing security measures. "Required" (R) specifications are mandatory measures. "Addressable" (A) specifications may not be implemented if neither the standard measure nor any reasonable alternatives are deemed appropriate (this decision must be well-documented and justified based on the risk assessment). Here are the mandatory and addressable requirements for a HIPAA-compliant database. Mandatory HIPAA Database Security Requirements HIPAA Compliant Database Access Control Database authentication. Verify that a person looking for access to ePHI is the one claimed. Database authorization. Restrict access to PHI according to different roles ensuring that no data or information is made available or disclosed to unauthorized persons. Encrypted PHI PHI must be encrypted both when it is being stored and during transit to ensure that a malicious party cannot access information directly. Unique User IDs You need to distinguish one individual user from another followed by the ability to trace activities performed by each individual within the ePHI database.  Database security logging and monitoring All usage queries and access to PHI must be logged and saved in a separate infrastructure to archive for at least six years.  Database backups Must be created, tested, and securely stored in a separate infrastructure, as well as properly encrypted.  Patching and updating database management software Regular software upgrades, as soon as they are available, to ensure that it’s running the latest tech. ePHI disposal capability Methods of deleting ePHI by trained specialists without the ability to recover it should be implemented. By following the above requirements you create a HIPAA-compliant database. However, it’s not enough. All HIPAA-compliant databases must be settled in a high-security infrastructure (for example, cloud hosting) that itself should be fully HIPAA-compliant. HIPAA-Compliant Database Hosting You need HIPAA-compliant hosting if you want either to store ePHI databases using services of hosting providers, or/and to provide access to such databases from the outside of your organization. Organizations can use cloud services to store or process ePHI, according to U.S. Department of Health & Human Services. HIPAA compliant or HIPAA compliance supported? Most of the time, cloud hosting providers are not HIPAA compliant by default but support HIPAA compliance, which means incorporating all the necessary safeguards to ensure HIPAA requirements can be satisfied. If healthcare business wants to start collaborating with a cloud hosting provider, they have to enter into a contract called a Business Associate Agreement (BAA) to enable a shared security responsibility model, which means that the hosting provider takes some HIPAA responsibility, but not all.  deloitte.com/content/dam/Deloitte/us/Documents/risk/us-hipaa-compliance-in-the-aws-cloud.pdf In other words, it is possible to utilize HIPAA compliance supported services and not be HIPAA compliant. Vendors provide tools to implement HIPAA requirements, but organizations must ensure that they have properly set up technical controls - it's their responsibility only. Cloud misconfigurations can cause an organization to be non-compliant with HIPAA. So, healthcare organizations must: be ensured that the ePHI is encrypted during transit, in use, and at rest; enable data backup and disaster recovery plan to create and maintain retrievable exact copies of ePHI, including secure authorization and authentication  even during times where emergency access to ePHI is needed; implement authentication and authorization mechanisms to protect ePHI from being altered or destroyed in an unauthorized manner as well as include procedures for creating, changing, and safeguarding passwords; implement procedures to monitor log-in attempts and report discrepancies; conduct assessments of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI; include auditing capabilities for their database applications so that security specialists can analyze activity logs to discover what data was accessed, who had access, from what IP address, etc. In other words, one needs to track, log, and store data in special locations for extended periods of time. PaaS/DBaaS vs IaaS Database Hosting Solutions Healthcare organizations may use their own on-premise HIPAA-compliant database management solutions or utilize cloud hosting services (sometimes with managed database services) offered by external hosting providers.  Selecting between different hosting options is often selecting between PaaS/DBaaS and IaaS.  For example, Amazon Web Services (AWS) provides Amazon Relational Database Services (Amazon RDS) that not only gives you access to already cloud-deployed MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server or Amazon Aurora relational database management software, but also removes almost all administration tasks (so-called PaaS/DBaaS solution). In turn, Amazon's Elastic Compute Cloud (Amazon EC2) services are for those who want to control as much as possible with their database management in the cloud (so-called IaaS solution).  on-Premise vs PaaS/DBaaS vs IaaS Database Hosting Solution PaaS/DBaaS vs IaaS Database Hosting Solution Azure also provides relational database services that are the equivalent of Amazon RDS: Azure SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL, and Azure Database for MariaDB. Other database engines such as SQL Server, Oracle, and MySQL can be deployed using Azure VM Instances (Amazon EC2 equivalent in Azure). Our company is specializing in database development and creates databases for large and smaller amounts of data storage. Belitsoft’s experts will help you prepare a high-level cloud development and cloud migration plan and then perform smooth and professional migration of legacy infrastructure to Microsoft Azure, Amazon Web Services (AWS), and Google Cloud. We also employ experts in delivering easy to manage HIPAA-compliant solutions and technology services for medical businesses of all sizes. Contact us if you would like to get a HIPAA risk assessment and analysis.

Reducing Cloud Costs Before Migration: Building a Budget Companies often face overpayment challenges due to Azure's complex pricing, cloud metric misconception, and lack of expert guidance. A key step in preparing for these intricacies is developing a strategic budgeting plan that sets the foundation for a smooth migration. Key budgeting process focuses on: identifying and optimizing major cost drivers selecting the right hosting region to balance cost with performance choosing cost-effective architectural solutions defining the necessary computing power and storage requirements Addressing these aspects is essential to avoid unnecessary expenses and make informed decisions throughout the Azure cloud migration journey. Planning Cloud Resource Utilization Selecting the Appropriate Service As part of our cloud migration strategy, we conduct a thorough assessment of your current on-premises resources, encompassing databases, integrations, architecture, and application workloads. The goal is to transition these elements to the cloud in a way that maximizes resource efficiency, optimizes performance, and reduces costs post-migration. Consider, for instance, a customer database primarily active during business hours in your current setup. In planning its cloud migration, we assess cloud storage and access patterns, considering them a critical aspect. There are several methods for this, such as using Azure VM running SQL, Azure SQL Database, Managed Instance, or a Synapse pool, each offering unique features. In this scenario, for cost-efficiency, the Azure SQL Database’s serverless option might be the preferred choice. It scales automatically, reducing resources during off-peak times and adjusting to meet demand during busy periods. This decision exemplifies our approach to matching cloud services to usage patterns, balancing flexibility and cost savings. Our detailed pre-migration planning prepares you for a cloud transition that is both efficient and economical. You'll have a clear strategy to effectively manage and optimize cloud resources, leading to a smoother and more budget-friendly migration experience. Calculating necessary computing power and storage to avoid overpayment When migrating to the cloud, it's not a good idea to blindly match the resources 1:1, as it can lead to wasted spending. Why? On-premises setups usually have more capacity than needed for peak usage and future growth, with around 30% CPU utilization. In contrast, cloud environments allow for dynamic scaling, adjusting resources in real time to match current needs and significantly reducing overprovisioning. As a starting point, we aim to run cloud workloads at about 80% utilization to avoid paying for unused resources. Utilizing TCO Calculator for Cost Comparisons To define the optimal thresholds for computing power and storage, we evaluate your workloads, ensuring you only invest in what is necessary to build. There are tools like Database Migration Assistant (DMA), Database Experimentation Assistant (DEA), Azure Migrate, DTU Calculator, and others that can assist in this process. Our cloud migration team uses the Total Cost of Ownership (TCO) Calculator to provide a comprehensive financial comparison between on-premises infrastructure and the Azure cloud. This tool evaluates costs related to servers, licenses, electricity, storage, labor, and data center expenses in your current setup and compares them to the cloud. It helps you understand the financial implications of the move. Accurately Budgeting Your Cloud Resources with Azure Pricing Calculator After gaining a general understanding of potential savings with the TCO Calculator, we employ the Azure Pricing Calculator for a more detailed budget for your cloud resources. This free web-based tool Microsoft that helps estimate the costs of specific Azure services you plan to use. It allows you to adjust configurations, choose different service options, and see how they impact on your overall budget. Selecting the Region for Cloud Hosting When preparing for cloud migration, selecting the right Azure hosting region involves a balanced consideration of latency, and cost. Evaluating Latency Our assessment focuses on the speed of data access for your end-users. Contrary to assumptions, the best region is not always the closest to your company's office but depends on the location of your main user base and data center. For example, if your company is based in Seattle but most users and the data center are in Chicago, a region near Chicago would be more appropriate for faster data access. We use tools like Azurespeed for comprehensive latency tests, prioritizing your users' and data center's location over office proximity. Complexity with multiple user locations: Choosing a single Azure region becomes challenging, with a diverse user base spread across multiple countries. Different user groups may experience varying latency, affecting data transmission speed. In such scenarios, hosting services in multiple Azure regions could be the solution, ensuring all users, regardless of location, enjoy fast access to your services. Strategic planning for multi-region hosting: Operating in multiple regions requires careful planning and data structuring to balance efficiency and costs. This may include replicating data across regions or designing services to connect users to the nearest region for optimal performance. Evaluating Cost Costs for the same Azure services can vary significantly between regions. For instance, running a D4 Azure Virtual Machine in the East US region costs $566.53 per month, while the same setup in the West US region could rise to $589.89. This seemingly small price difference of $23.36 can cause significant extra expenses annually. Let's consider a healthcare enterprise with 20 key departments that requires about 40 VMs for data-intensive apps. If they choose the more expensive region, it could add around $11,212 to their annual costs. So, the decision of which region to choose is not just about picking the lowest cost option. It involves balancing cost with specific operational needs, particularly latency. We aim to guide you in selecting a hosting region that delivers optimal performance while aligning with your budgetary constraints. This will ensure a smooth and cost-effective cloud migration experience for your business. Reducing Cloud Costs Post-Migration Transfer existing licenses If you have existing on-premises Windows and SQL Server licenses, we can help you capitalize on the Azure Hybrid Benefit. This allows you to transfer your existing licenses to the cloud instead of buying new ones. To quantify the savings, Azure provides a specialized calculator. We use this tool to help you understand the financial advantages of transferring your licenses and discover potential cost reductions. Our goal is to ensure you get the most value out of your existing investments when moving to the cloud. For a 4-core Azure SQL Database with Standard Edition, for example, Azure Hybrid Benefit can save you about $292per month, which adds up to $3,507 in savings over a year Continual Architectural Review for Cost Savings After migrating to Azure, it’s vital to review your cloud architecture periodically. Cloud services frequently introduce new, cost-efficient alternatives, presenting opportunities to reduce expenses without compromising on functionality. While it's not recommended to overhaul your architecture for small savings, substantial cost reductions warrant consideration. For instance, let's say you initially set up an Azure virtual machine for SQL Server, but later discover that Azure SQL Database is a more affordable option. By switching early, you can save on costs and minimize disruption. To illustrate, consider a healthcare company that moved its patient data management system to Azure using Azure Virtual Machines. This setup cost them $7,400 per month (10 application server VMs at $500 each and 3 database server VMs at $800 each). However, after implementing Azure Kubernetes Service (AKS) and Azure SQL Database Managed Instance, they reevaluated their setup. Switching to AKS for application servers and Azure SQL Database Managed Instance for databases required a one time expense of $35,000, which covered planning, implementation, and training. This change brought their monthly expenses down to $4,500, (AKS at $3,000 and Azure SQL Database Managed Instance at $1,500), resulting in monthly savings of $2,900. Within a year, these savings will have offset the initial migration costs, resulting in an annual saving of approximately $34,800. Autoscale turning on and off the computing resources on demand Azure's billing model charges for compute resources, like virtual machines (VMs), on an hourly basis. To reduce the overall spend, we identify and turn off resources you don't need to run 24/7. Our approach includes: We thoroughly review your Azure resources to optimize spending, focusing on deactivating idle VMs. Organizing resources with clear naming and tagging helps us to track their purpose and determine the best times for activation and deactivation. Resources used for development, testing, or quality assurance, like Dev/Test/QA, often remain idle overnight and on weekends. We can automate turning them off when they're not needed, resulting in significant cost savings. Compared to production VMs, the savings from these resources can be substantial. For example, consider an organization with 1.5 TB of production data on SQL Servers, primarily used for monthly reporting, costing about $2,000 per month. Since these systems are idle about 95% of the time, they're incurring unnecessary costs for mostly unused resources. With Azure's autoscaling feature, the organization can configure the system to scale up during high-demand periods, like the monthly reporting cycle, and scale down when demand is low. This way, they only pay the full rate of $2,000 during active periods (only 5% of the month), reducing monthly costs to around $600. Annually, this leads to saving of $16,800, a significant reduction in expenditure. Cost-conscious organizations can effectively handle and save on cloud migration expenses by partnering with Belitsoft's cloud experts, who handle Azure migration budget planning and ongoing cost management. Contact us to involve our experts in your cloud migration process.

Talk to our data warehouse consultants Data Warehouse vs Database Of course, when all you have is a hammer everything looks like a nail. The more detailed picture demonstrates that it's more cost-effective to use the right tool for the job. A Database is used for storing the data. A Data Warehouse is used for the analysis of data. Database You are using a Database (DB) during your daily activities for entering, storing and modification transactional (that is, statistical) business data.  This can be detailed information about what you sold to whom and when: the Сustomer #1 from Segment #1 bought three units of the SKU#1 on the 10th of March 2020).  There can be tens of thousands of such entries per day. So you can’t use these data as a basis for decision making without initial preparation.  To prepare the data for analysis, you have to :  download the data from the DB; upload it to the special software (e.g. Excel, Power BI, Tableau, etc.); make your calculations. The more calculations you need to do, the more time they take, and the higher the chances of making a mistake are.  Only after this, the data can be used for decision making. Data Warehouse A Data Warehouse (DWH), as usual, is a set of databases. A data warehouse stores both statistical and aggregated data. A DWH is created primarily to analyze data for decision making.  A DWH could be the source of the following aggregated and calculated data: Total Sales (by Location, Category, SKU, Period, and more). For example, all Сustomers from Segment #1 bought 100 000 units of goods from Category #1 brought $1,000,000 in March 2020; Total Sales Growth (by Location, Category, SKU, and more). For example, it increased by 100,000$ or 10% in March 2020 compared with March 2019.  Budget Vs. Actual (by Location, Category, Period, Сustomer Segment, and more). For example, the actual variance is $10,000 or -10%.  and so on. These data can be used to create models, e.g. to predict demand for goods from Category #1 from Сustomers from the Segment #1. The data for the analysis are automatically loaded and precalculated in the DWH so you don’t have to spend financial resources on specialists’ salaries to get analysis-ready information. This also negates the possibility of human error. A data warehouse is different from a database in that it contains aggregated and calculated data for analytical purposes. This is why you can’t do without a DWH if you need analytics for making business decisions. Using BI without DWH you could face such risks as: Business data loss. Risk of incorrect analytics due to business data loss (loss of data due to temporary connection glitch, denial of access to the data during report generation, loss of access to the historical data due to its deletion at the source). Performance issues. Using analytics could be impossible due to the BI-tool freezing, crashing, or becoming unresponsive. Check out other benefits of a data warehouse.