Migrating 80K SQL Server databases to AWS: A strategic ISV journey

Imagine, imagine yourself wearing a yellow helmet. I know you're probably thinking, does it have to be yellow? Yes, it has to be yellow and you will know why in just a moment. Yes, that's you wearing the yellow helmet geared up with your own parachute. Looking out the open door of a flying airplane at 14,000 ft above the ground.

Now, the question is, would you take the jump? How does that even make you feel? Are you excited or overwhelmed? For me, that image is all about excitement because it reminds me of one of the most memorable experiences I have ever had in my life. And I'm here to share with you that I found five key elements that helped turn my overwhelming goal into an exciting one.

If you found yourself more on the overwhelmed side and not excited, imagine yourself in that yellow helmet moment. Again, only this time, I will give you a quick overview and a background around those five key elements that happened prior to that moment. See if it changes your mind or how you feel about it.

What if I told you you spend the whole day in a ground class planning for every single detail of that jump, you would know exactly where you take off from how much altitude you will gain. And more importantly where your landing zone is. You would also know how the dynamic elements of that jump would impact your plants.

You see those blue and orange lines on the aerial map of the landing zone. Those are the different landing patterns that you would take depending on the direction of the wind as you get closer and closer to the ground.

What if I told you, you get to familiarize yourself with all the tools that you need for that job, from your safety tools to your essentials, like how your parachute works, how your reserve chute works. You would also learn how to work with some monitoring tools like your altimeter that will give you the exact altitude at every moment. And it would also remind you of some of the key decisions that you have to make along the way.

You see that red area marking the 2500 ft on the altimeter. That's the key decision altitude at 2500 ft. You would make a decision whether or not you can safely land with the parachute above your head and if not, you would pull your reserve.

What if I told you, you get to practice and feel the power of the wind hitting your body at speeds of over 100 20 mph and you would practice how to harness that power. If you want to go left, just tilt your hand slightly to the left and you will start moving left, you wanna go right. You guessed it.

What if I told you, you are not going to be doing this on your own. You would have experienced experts jumping through the cloud with you just to be your support. And last, but definitely not least what if I told you, you had the opportunity to hear the lessons from the experienced experts who have done this thousands and thousands of times and they would do it comfortably.

Now, the question is, would you take the jump out?

My name is Amir Ibrahim. So today and I'm a Microsoft specialist solutions architect here at AW as part of my role at a WU si have had the privilege to help some of the most strategic and global a W us. customers migrate mo modernized and optimize their Microsoft workloads on AWS.

Today, I'm joined here with my very great friend and colleague, Jackie to and a very special guest speaker, Andre Lo Meo, the VP and CTO of SAP Concer. I will now hand it off to Jackie to go quickly over the agenda for today's session.

Thanks, Amir. So how many of you guys are skydivers? See a raise your hand. I'm not um just to quickly go over kind of the, the agenda and this could be very trivial. You can apply this to any kind of things that you do in life, right? Typically, it's around the goal setting, it's around the planning, the tools, the training, the supports that you're gonna get with coaches, et cetera. And then in our case, specifically for SAP Concur lessons learned from previous experiences as well. And then finally, we end with a Q&A.

Now again, if the scope of this is overwhelming to you don't be threat, this is what AWS is here for, to help you with. And also to hear from Andre, let me introduce you to Andre. Andre is the CTO and VP for SAP Concur. Uh he's responsible for all the engineering efforts for mobile services, uh the travel management companies, the Trip Link and Trip It as well. And also he's also the uh responsible for co-author for the Evolution of Travel, which you'll hear more from Andre as well.

Um previously to SAP Concur, uh he worked at Microsoft um doing all the engineering efforts for Microsoft Dynamics. And he also previously worked at Cisco covering the Webex contact centers with that. I'll turn it to Andre.

Thank you. So if you don't know, Concur, Concur is the leading provider of integrated travel expense and invoice management solutions. We serve over 65,000 customers worldwide and that includes over 70% of all Fortune 500 companies. We are a trusted partner for businesses of all sizes across all industries. Our service runs at scale. We operate over 30 million expense reports per month and we operate over 5 million travel bookings per month.

A business of this complexity have requirements and we keep on the modernization front trying to evolve our business and our staff and our offerings. So we have a couple of goals for, for that evolution and one of them was to consolidate our data centers. So we had a co location based cloud offering and our integration. Our pre-production environments didn't really look the same as our production environment. So part of our goal was to consolidate, make them look the same, make them be exercised the same.

We also wanted to improve our agility and productivity. In other words, we wanted to build more features other than, you know, investing on infrastructure and devote our staff to it. Um we want to expand, have a broader and global reach. So we wanted to streamline that process make us ready to expand more rapidly. And lastly, we wanted to work on optimization of costs. We wanted to make sure that we have an increased value margin, right?

All of that led to thinking about migration to AWS um and stop doing our colo location. Why do we pick AWS? Well, AWS had an extensive experience and proven reliability on the cloud. The security and compliance posture met our business requirements and the constant evolution, the constant pace of innovation met met also matched also our hunger for innovation so we have that migration was complex.

We had a problem, a good problem. We had over 65,000 customers operating worldwide. We needed to have 24 7 availability of the service in terms of microsoft workloads, we had the over 85,000 sql server databases running. So our goals were simple and easy if you, well, maybe not as easy.

We wanted to migrate 100% of our commercial customers to AWS. We wanted to leave no trace of our cold environments want to keep the customers running before. And throughout the process, we wanted to adopt as much from AWS technologies as we could. We wanted to really get out of the business of owning our infrastructure, owning our tooling to support our business. We wanted to make sure that we use best of breed of cloud available. And like i said before, we wanted the ability to expand to new regions as publicly announced, we're going to be expanding to tokyo in the next year. We wanted to have that road map be an easy target for us other than worrying about where is our physical data center gonna be, how we're gonna procure hardware and things like that.

So uh an operation of this magnitude requires some planning, how much planning well for us over two years of planning and then we executed that migration over three quarters. And right right now, today, we are doing efforts of right sizing the environments i would like to say that two years is a long time to plan an exercise like this and we run into risks because it took so long.

So first of all, during 2020 to 2022 we have something very little but maybe not so little. We have covid covid the incident and that triggered for us an sap concur a lot of resource journey, a lot of adaptation to the new era and that triggered the delay in our plants in our processes that delay made the plans age out. So the tooling and infrastructure that we have analyzed we had studied from before that we had the plan to migrate to. Well, wasn't exactly on, that wasn't exactly up to date by the time we started executing on it.

So the other thing that we had to consider were tco based decisions. So a lot of like i mentioned before, a lot of our goals were about cost reduction, improvement of our value margins. So we had to analyze and in particular for microsoft workloads, we have, we came across three tco based decisions.

So the first one, the first tco based decision was whether we would continue doing our microsoft workloads, hosting them ourselves. In this case, in on amazon ec2, or we would migrate database technology completely into a managed database service like amazon r ds.

The second tcu item that we came across is um we have licenses for our microsoft workloads the license consumption was being consumed faster than expected. So we had to make adjustments very quickly. And the last thing is rate sizing we want after the migration, during the migration, there is a cost associated with that we wanted after the migration to work for uh improvements in our value margin, reduce our cost of ownership.

So those are the three big total cost of ownership decisions and activities that we did mostly in relation to our microsoft workloads. So like i mentioned before, the first tco decision that we spent quite some time analyzing was whether we would self manage our microsoft workloads or we shift database technology into r ds.

We evaluated a lot of domains for that effect. Like what is the infrastructure going to look like and maintenance activities? How's the security going to be? Does it match up to our security requirements? What about our backup policy and how we can keep uh our redundancy efforts like high availability, disaster recovery, our requirements that we have for the business, how we can implement them eventually boil down to a decision?

Do we take the administrative overhead of managing our own database at uh less costly license option versus a higher cost managed offering? But that saves us from administrative overhead. Um the decision from the business was to go into a cost was cost based. So we end up keeping a self managed microsoft workloads on amazon uh running on amazon ec2 with a license with a bring your own license model.

Speaking of licensing, it is not as straightforward as a pay as you go and bring your own license. There's actually quite uh um a high amount of options available. There are flexible pay as you go, options for licensing, but it's also the bring your own license, which is the model that we consume. And out of those, there's the shared tenant for license, mobility with software assurance plan and that's what we use.

And there's other options that are available to be evaluated. So specifically for the Microsoft workloads, after we made a decision that we're gonna keep our self hosted option and bring our own license to AWS. We had to investigate and study the tools to understand how to perform that migration.

So, fortunately, AWS has a wide collection of tools that made this made easy for us to uh to undergo that process. There are tools that we use during the migration and there are services that we use post migration to keep our business requirements. So during migration, we use the uh AWS Migration Hub, the Application Migration Service and the Database Migration Service. After we migrated, we used the services for disaster recovery to implement disaster recovery.

At Concur, we use the simple the S3 for the storage service and all of the options that it provides including um encryption and en and uh including access control. We use that to uphold our security and our encryption requirements and we use AWS Backup to do our backup policy and our disaster recovery.

Um even despite the help of the tools, despite the help of the experts that helped us along the way, despite the help. Um uh despite the plan that we have going on, it was still very highly complex for us because Concur has um a collection of challenges the way we operate that made it a little bit less optimal to undergo a migration like this.

First of all, we have dispersed customer data across many different internal databases. So we have databases, there are particular like tenant specific, we have databases, they have, they are multi tenant. So picking out the data for a single tenant to undergo the migration again, like i mentioned, all customers needed to stay running all other customers while one customer is being migrated, needed to stay running. So we couldn't just drop the database and uh reapply it somewhere else. It it was a little bit more complex than that.

Um like i mentioned, we do have single tenant and multi-tenant databases that we have to manage. Um and we had to do it while the service was running on the sourced environment and on the running on the target environment without disrupting, disrupting the existing customers.

So those are the migration challenges and to enable to have that, we, we did build a special tool called Migration Orchestration System and the purpose of that tool was to essentially collect the customer data for a particular customer undergoing migration and transition that customer without affecting any of the other customers, regardless of how dispersed the data was or how dispersed the customer layout was.

So we did get some help from some training. So I'm gonna pass on to Jackie to talk about that. Yeah. Can we hold the questions till the end? That'll be great. Thanks.

In terms of the training, um if you think about it, SAP Concur is a very complex uh environment and uh what we are here here is to provide the training necessary to help the team. So if you look at it for any kind of engagements out there today, right?

Um AWS coming in, fresh into a company like yourself, some of you guys might be new to migrations or new to AWS. Some of you are existing customers. Um what we don't know is who are we actually interacting with from the contact point of contact? Some of us might be interacting day to day with folks that are very involved in the overall planning process. And then some of us get pulled in into the migration process.

So we don't know what the skills gaps are and what the technical gaps are. So one thing that we do with Concur was put together and what we call EBA party. So for those that don't know what the EBA party is Experience Based Party where we identify some of the skills gaps or technical gaps for the specific company or the divisions of the business units.

Um in specifically for Concur, we did a migration EBA in 2020. This was right around the time of the Covid. As Andre mentioned from there, we've identified specific deep levels of content and knowledge that needs to fill those gaps in order to kind of move forward with the migration and not more just for the migration itself, but like sustaining it throughout and have it operating going forward.

Um this is where we have the AWS Immersion Days. Um for those that don't know, again, all these trainings are available to you. Please take advantage of them. Um these are very specific hands on trainings that we use to help with certain services or products within AWS. In this case, Concur we looked at AWS License Manager which allows them to uh tally and calculate and also be able to move between the share tenancy model as well as dedicated host model by using a License Manager.

And then finally, if because most of the EB A parties and immersion days are very involved and it requires you to pull teams away from your day to day schedule. What we also have our lunch and learn series where we sit down with your team to come up with a series of lunch and learns lessons and sessions, doing those brownback lunches at with your company to help to not disrupt your operations.

In this case, we looked at performance monitoring with Amazon CloudWatch. Now you might think about, well, you know, one thing that AWS has a lot of is uh experience experts. And so here we spend a lot of time and actually with Andre and his team to even on a weekly basis to work through a lot of these different scenarios planning executing um as we go through the whole migration and now to the right sizing.

So some of the experts that you might get involved with on the um on your side as well, are the account teams as you know, aware, this is your single point of contact for a lot of your engagements. Um within AWS, we also have specialists like Amir myself who handles uh Microsoft workloads. We also have specialists that figure um that get involved with the R&D side of the business storage is another example as well as even observer and containers as well.

So um the third teams that you might get involved with is uh the technical supports. So those are the technical account managers that help with some of the disaster recovery or fail points that that might happen, any escalations, capacity issues that you might need to get uh contact with and also to make reservations around your capacities.

Um for folks that are needing need help with staff augmentation, we do have a professional services available to help you augment your staff to help accelerate the migrations and also to fill in some of the knowledge gaps that may or may not be learned over either an immersion day or EB A or a lunch and learn series as well.

And then finally, we have partners. In this case with Concur, we use a licensing partner to help with doing the licensing optimization and also help with the wave planning in terms of the migration so that we make sure that the the licenses that are involved and the costs that are involved are minimized to the appropriate level.

So here's a good quote from a dear friend of mine now. And who works for Andre is if you read them from the slide itself, we we know there's a lot of specialists and a lot of teams and AWS. But one thing to be sure of is there, you know, our account team is there for you to help you with bringing the right required experts to the table.

So I think Andre mentioned earlier about something called the TCO and I've also mentioned something called optimization and licensing assessment. I'll just run through this really quick for all of you is for us to get a very good sense of your environment and your cost environment, we really need to know the baseline.

So we have tools available to help with either pulling your environment or um manual spreadsheets to help with getting the data that we need to do the optimization. This is very crucial because it's no longer, we're not, no longer specking for the high peak of the on prem environment. We're specking for what's ongoing usage of the cloud environment.

Understanding the costs, not just the cost for your infrastructure but the cost for the licensing as well. And then finally, we talked about building the plan. So what's the migration plans going to look like? What is, how are we going to execute across and be able to deploy the right licenses to the environment?

You're gonna have a time where there's going to be a double bubble cost too. You're gonna have on prem environment, you're also gonna have your cloud environment. So that, that needs to be thought through.

Um with that said, um this is kind of the trajectory of the savings that we did at Concur and obviously, these are all in percentages. So you see back in January of 2023 2023 we started at a pretty high water mark when the migration finished.

Um as every month go forward as we are executing and working with Andre and his team to help with optimizing those scenarios every single month, we've been able to bring the cost down significantly over the course of the six months. And this includes um mapping some that we initially used for the migration as well as making sure that the iops for example, is appropriate for the workloads.

So overall the savings here, if you accumulate across the board, we're projecting about 72% savings over the initial migration. So what does that mean? Right. If you bring it all back the journey itself for any kind of migration involves coming into AWS at a relatively fair break, even cost similar to what your on premises have today.

But we do have experts in place and the programs in place like the OO A program and our specialists to help you kind of go through the uh down the cost curve as well. And as you go down the down down curve, you'll be able to free up some of your the funding that and the cost that necessary to help you with your innovation.

And what what we try to do as the specialist is to kind of make you go through that journey and help you through from migration all the way to modernization and in between of optimizations of different levels.

So with that, i would like to hand it over back to Andre and talk about some of the lessons learned. Thank you.

So the lessons learned that i would like to call out the i would say the top two is be firm on the goals like when you have a migration plan, you have to execute it quickly because the plans can get outdated, that the innovation will happen. And then there's the needs of the moment i'll talk about that in the next slide.

The other thing that i would like to say is if you are in a leadership uh situation and you have your teams operating that migration support your teams from a top down strategy, like make sure that it's the priority one or priority to on your road map. And that other things that come along don't intercept, that don't derail the team.

So this sort of the two learning aspects because it it they did play a part in the Concur uh um in the Concur migration.

So one of the things is the if you detail the first one a little bit further, the needs of the moment will come. So if you're serving customers and the customers will bring needs new features, new requirements and the longer the process is, the more likely those requirements will add pressure and will cause the team to derail and cause the team to reinvest and further the initial objective of the migration will be compromised or delayed, right?

So do the reverse, shorten those timelines and invest more of your capacity if you can. So that would be my advice if you have a similar situation.

The the other thing is do the planning, do a deep planning, the more you know, ahead of time, the better the plan. So know the tools know the available services, learn from other companies just like Concur here is doing uh learn from other companies and how the experience can look like.

Um the other thing is don't make plans for executing in two years like the plans will age out, there will be new tools, there will be new capabilities, there will be new vm instance types that you can leverage, that will save you the cost. So how do you predict today might not be the best optimal solution in two years from now?

And the other thing is that is a really cost critical decision that you have to do is explore the licensing options carefully and scale them out.

Amir is gonna talk about the compute and the matching between the colo environments and the and the compute costs. But i did mention before that our license entitlement was being run faster than expected. That was because we were consuming more cores and therefore more licenses than expected because we made a comparison saying we need this amount of cores in colo, we need the same amount of cores in aws and that was the wrong as assumption.

So explore the licensing options and evaluate that as part of the plan. That would be my advice

Um, like Jackie mentioned, there is a time that you're going to have both the colo environment or the on prem, whatever the situation is, as your starting point. Um, and the AWS cloud environment target, right? They were operating at the same time. So there will be a cost added on during a period of time. That cost will peak during the migration because you have more workload activity during the migration. You're transferring the data or you're um exercising the scale more than you were doing before. Before there were no customers, right? So the cost was gonna peak up. But then after it reaches a sustained level of execution, that's when you start the cost optimization.

So um, I was very just like Jackie was mentioning, I was very concerned with costs from the beginning of this process and showing outcome in terms of cost was very difficult. It was not possible actually to do it during the migration. But now we can show the cost improvement, post migration. So that's when the cost optimization portion of the exercise will come. And I did speak through the notes before the notes were showing, but that's what I meant, right? So I'm passing on to Amir. I talk about the the computer.

Ok. So let's dive a little bit deeper around um the technical lessons learned and takeaways that we have uh based on this migration. And one of the most common questions that I get as a solutions architect in the Microsoft software codes team is you have over 750 different type of instances available on AWS. How do I pick which instance is the right one for my specific workload?

The answer is an answer that you most probably have heard a lot from solutions architect. Does anybody know what that answer is? Thank you. It depends. And it's not because we're trying to avoid the question. It's because it actually truly really depends. But let's talk about what does it depend on in specific and specific to SQL Server workloads?

It depends on the type and the nature of resource utilization of your specific workloads. Meaning is your workload more memory intensive? Is it more CPU intensive? Is it more IOPS intensive? And what is the ratio of the resource utilization across these different resources? So in order to answer that question, you need to know your numbers. You have to have enough performance monitor monitoring tools in place that you can answer those questions and you have to be able to benchmark and test those numbers to see if they are right or wrong.

And one of the key metrics that you are looking for is the memory to CPU ratio for SQL specific workloads. They tend to be memory intensive, meaning you are going to need more memory than the number of cores of CPU to run your SQL Server workloads. And that the answer to that ratio is gonna define the type of instance families on AWS that you are going to use. Typically, those instances on AWS would be the R series instances or if you really need a higher level of memory to CPU ratio, those would be for example, the X to I3 DNS.

So that's one of the numbers that you want to get to um and know in order to find that right instance.

Second, you want to be on top of the pace of innovation on AWS. We continuously are improving the different instances and families that we uh release. And with each new generation of these instances, typically you get somewhere between 10 to 15% better price performance.

Now another question, as soon as a new generation comes in, do I have to migrate and change my instance types to that new and latest generation? The answer is it depends. Yes, in a vacuum, you want to migrate as and change your instance life as soon as new generations come in. But there are other factors like your TCO that you have to keep in mind.

As an example, you might have already opted in for reserved instances and you have bought reserved instances for a certain instance family that is going to give you a lot of discounts for that specific type of instance types. So at that point, unless you are willing to invest on a new set of reserved instances, it might be on the interim, a better decision to stay where you are and then move your reserved instances.

Talk to your AWS representatives and account teams to see how you can take advantage of the new generations.

Now, this is something that we talked about around the course. So what happens is your SQL workload is memory intensive, meaning you need more memory than CPU and specific to sequel workloads. You might end up on the larger size instances just because you need that additional memory. But these are the t-shirt size instance families. Meaning in every family, the ratio of the CPU and memory is gonna stay the same even though you're going up in size on that specific instance family.

What that means is for you to get to that memory that you need, you might end up getting a lot more cores of CPU that your workload doesn't actually need. Now, the caveat is SQL Server workloads and specifically licensing is going to be based on the number of cores that you have available to your instance. So you will end up paying more for the number of cores that you are not even using.

That's where one of the greatest features of Amazon EC2, the optimized CPU comes in. Using the optimized CPU, even though you have on opted in for those larger size instances to get that memory, you can disable those CPU cores at the virtualization layer and the Nitro level on AWS. So you don't have to pay for the extra licenses for the cores that you need even though you're getting the additional memory that you need it.

And this one I believe, Andre touched on a little bit. Um, when will you have been running SQL workloads or Microsoft workloads in general for a long time on premises and in colo locations, there are certain kind of mindsets that comes with us running these workloads for a long time in that environment. The the game is different in the cloud in your colo locations and on premises.

You do not have memory or other resources available to you readily. Meaning you have to size your environments for peak at the beginning, because when you get to that point that you need additional memory you don't have, it's not possible for you to just turn on a switch and add additional memory in your colo data center. You have to plan for a lot of things for that to happen.

That story is different on the cloud. You do have memory and other resources available to you as at the time that you need it and on demand. So you don't want and you don't need that headroom that you are used to have for your workloads on prem in the cloud. You can just size your environments based on the needs that you have. And as the load on your servers goes up and your workloads goes up, you can easily change and take advantage of the elasticity of the cloud.

Now, let's talk about a little bit about the storage and networking for these workloads. I touched on this. Um, you want to know your numbers, so you have to benchmark to know where you are staying at and you want to continuously monitor your performance specifically around storage and networking.

What happens with SQL Server workloads around IOPS and throughput is I use this analogy sometimes. Think of of a very powerful car with a very powerful engine. If it doesn't have good tires that gives you enough traction on the road, it doesn't matter how powerful your engine is, you are not gonna get to the speed that you want if you cannot bring that traction in.

That's the same story with your SQL Server workloads with high CPU, high memory, but low level of IOPS and storage. If your storage option is not capable of addressing the needs of the IOPS and throughput that you need, it doesn't matter how much powerful your instance is, that storage is not gonna be able to address that kind of a load.

On that note, you want to opt in specific for SQL workloads onto instances that are EBS optimized instances. EBS optimized instances are the type of instances that have a dedicated channel between your instance and the storage service, EBS. With that you can get a consistent and persistent performance for your storage.

Now, another option that you have is typically you are gonna be using EBS or Elastic Block Storage as your storage with different options that you have on AWS for your SQL workloads. However, specifically with the SQL workloads that are legacy applications and legacy database applications, we tend to find a lot of the business logic developed at the database layer, meaning you have a lot of the logic and the business application developed within stored procedures, triggers and so on at the database level.

And what that means is typically these workloads are very temp DB intensive, meaning they read and write to the temp database of SQL Server a lot and they require a lot of IOPS for that. One of the advantages that you can have is taking advantage of the instant store storage volumes on AWS instances. You can find certain instance types that provide that type of a storage, which is basically a local storage to that instance. And it doesn't have to go through that channel for EBS. So you are actually offloading some of that IOPS and throughput that you needed for your workload to that instant store volume and you have more room for your actual data requirements on EBS.

Next, keep in mind, not only there are some instance le uh there are some EBS volume level limits for what you can achieve with a certain type of a volume. There are some instance level limits too.

Yes, and EBS GP3 volume can give you up to 16,000 IOPS. But that doesn't mean you can add and stack as many EBS volumes as you want and expect to achieve the sum of the IOPS from all those volumes because there are certain limits that are applied at the instance level. So keep both of those limitations in mind when you're architecting and sizing your environment for SQL workloads.

And lastly, one of the options that you have to bypass those volume level limitations is striping your volumes together to get to a higher level of IOPS and throughput.

Now, we all know SQL Server has been around for quite some time. And when you integrate SQL Server into your application stack and start using it for your storage, uh data storage needs, we tend to use SQL Server for any kind of use cases that comes our way because it's convenient, because you have already implemented that integration and data tier.

But the world has changed. You have a lot of options available to you that are purposefully built for the very specific use cases that you might have. So it might be a good time to start rethinking and reimagining your data storage needs.

Next time when you want to start using SQL Server, think about your use case and see and explore if there are better options that are better suitable for that specific data usage.

I'm not gonna go through all the other, all the options that are available there. If I want one message for you to take away on that slide with you is to just remember every time you are using SQL Server, is it actually designed to address your specific data storage requirement?

There's only so much time in one hour uh that we can have a lot of content in that one hour. But for those of you who want to know more, the first link is a very specific prescriptive guidance around migrating SQL Server workloads to AWS. You can find a lot of good content there.

The second one is the optimization and licensing assessment that Jackie uh went through. If you want to know more about that, um you can take a look at that one and the third one is actually a description of all the other database, purpose built database options that are available to you there.

Um, I'm gonna keep these links there so you have time uh to take them, but please take a moment um to fill out the survey. The surveys are actually how we are gonna know what you like, what you don't, what works, what doesn't work and basically would be the basis for us to define the sessions for the next Rein event. So it's really important for us to hear from you where we did things right and where we did wrong.

Thank you so much uh for your time. Um thank you so much, everyone. Appreciate it.