Hi, welcome to the big commerce podcast. Hello, everyone, and welcome to the fourth episode of The Big commerce podcast the fundamentals of replatforming. First of all, thank you all for the continued support, we hope that you are finding value in the content we are sharing with you during this podcast. And of course, feel free to suggest the new topics you would love us to discuss in the upcoming episodes. Today podcast is about replac forming. We come across this kind of project very often this period, because many of our clients and a lot of merchants, I'm reading from other platforms. This is due to the fact that Magento one, for example, is coming to the end of life. So actual merchants, after huge need to move and migrate to another platform. Or even because sometimes merchants find their actual ecommerce platform outdated, and legacy really not functioning for the new needs and new features that need to instal and use for their e commerce. It's not a simple project as a usual design and development ecommerce platform project. The new site when you add new products and new features, and you start from scratch with the designing and with the architecture of the platform is a totally different project than migrating something that is already existing. And in which you have to adjust a lot of elements, a lot of integration from an old system from an old architecture to a new one. There are a lot of risks related with this. And only good planning can avoid the consequences of a bad migration for replatforming. For example, you can risk the loss of the search engine results that you already have for your actual platform. You can risk confusing the customers do the change of the design on the user journey. For example, I lifetime values product, the ones that are repeated purchase, they have repeated purchase, they might suffer a lot a confusion of the customers finding a new funnel, reaching the cart or a new process to get into the checkout and buy their own the goods. Ultimately, all the roads lead to this loss of revenue. Because if you put all these pieces together the result of having clients dropping your new platform because they feel confused, or because they're not finding your platform anymore. Translate itself in a loss of revenue. Today with me, as always, Luigi is gonna tell me about the replac forming. And he's going to give us the insight from his point of view from the point of view of urgency. Thank you very much. So replatforming projects, we come across very often the majority of clients that we work with a migrating to big commerce. So we find ourselves sitting down and hat and talking with customers when when we starting off the project to really understand the reasons why they are replatforming from their current platform replatforming It sounds easy, but it really shouldn't be a decision that's taken lightly. There are more risks than benefits in the short term. Although of course, the whole point of a replatform is to reap the rewards of changing platform of changing ecommerce software. So the questions you need to ask yourself when you are considering re platforming whether to actually analyse and evaluate whether re platforming is actually for you, is around about four kind of core questions. The first one relates directly to the actual platform. So we've had merchants that have approached us saying, look, you know, we've had some growth, and we are continuing to grow, but just the platform's not keeping up. So they've outgrown their ecommerce platform. And that happens quite a lot, especially with startups that start off on a cheaper platform, just to you know, for speed to market. And obviously, low low costs, which is growing or the market is becoming bigger or smaller. So you have to adapt your platform. You do it, but you also need to make sure that you maintain your competitive advantage. So you know that the platform you may not necessarily have outgrown. But actually now the platform no longer meets your needs because you you don't want to be the same as your competitors, you need to add an advantage. And if you can't do that necessarily on the product or the price, then you need to do that within the actual experience. So you know whether it's a Simple as offering subscriptions on certain products, or you know, bundling or maybe a b2b capability. So not just outgrowing the platform, but also making sure that the website meets your needs and or the needs of your clients. Yeah, well, was this the topic of having a really good experience, and most of the time is the core value for the client that is landing on your platform, a better better experience, sometimes outgrown and make clients choose your website, despite other ones just because it's easier for them and they feel in control. Exactly. And controls are really, really important. So I mean, even this morning, we had a conversation with a merchant of ours who was talking about scalability. And one of these questions was, you know, how will the server's be able to handle any growth, because it's a merchant that appears on TV, so they get these spikes, you know, when, when their product is featured, and when the story is featured. And so what you also don't want, especially if you are on a self hosted solution, is to find that actually, when you need the platform to perform, when you need the host to perform, because you're getting that spike in traffic, or when you're getting that growth in visits, they increase in visits, you don't want it all to fail, because it's just nonsensical that, you know, the, the, the busier you are, the less you can actually transact. So, you know, it's not just have you outgrown a platform, but is the is the platform actually suitable for your needs. Cost is a very big factor. And this tends to be kind of two opposites, really, I think more so than than in the middle. So you tend to have the startups that really have to count the pennies. And so you know, when you've got something that can cost them 10,000, to develop as opposed to 20,000. You know, they obviously need to make sure that the budgets balanced. And accordingly, kind of at the other end of the scale, where you need to then have internal resources to manage, you know, hosting and updates and upgrades. In the middle, I think, you know, they're just a bit more comfortable. But you find the budget comes up quite a lot, as I said, kind of in the startups, and the kind of lower ends, and then at the higher ends, where budgets are very, very strict and enforced very strongly. So cost is is a factor. And then, like we've just seen now with Magento, one, that the platform is no longer supported. So, you know, at the moment, I think the majority of the platform, the projects that we're working with, are Magento, to bigcommerce re platforms. And that's not obviously an everyday occurrence. But these, this has been the case for years, you know, Magento announced, I think, like five, maybe more years ago, that Magento, one was been sunsetted. And obviously, then it got extended. But you know, you you have that kind of, you know, you have that reason for replatform. Because you know that that end of life is going to come up and the platforms that are going to be supported. So before you undertake of replatforming, ask yourself, why are you replatform? Have you outgrown the platform? Is the platform holding you back because it's not offering, the features that you need in order to grow? Is the cost of running the website too high. And whether that's hosting costs, or resource costs, because you've got to have a developer that, you know, adds patches and updates and upgrades and all these different things? Or obviously, is it because the platform's no longer being supported? So what are the question that you need to ask yourself when thinking about replac forming, so what whilst in a replatform, there's advantages, and there's benefits and risks, we also need to be wary of by products. Because these sometimes are not so obvious. When it comes to replatform project, you've decided you need to replatform or you want to replatform What's the next steps? Well, you're gonna have to research platforms and agencies. And that takes time. So, you know, if you, if you haven't got a particular platform in mind yet, then obviously you need to undertake your research, whether that's reading blogs, whether that's going to trade shows, whether that's speaking with an e commerce consultant, or directly with the main, you know, e commerce platforms that that you know about, and that time is a cost for the people that are involved. The next is to evaluate them. So how are you going to benchmark the agencies and how you can benchmark the platform's how you're going to start filtering, which vendors and you know, which systems integrators and consultants and agencies you're going to work with. And again, that time has a cost attached to it. Thirdly, once you've decided on the platform, once you've assigned the brief to an agency or signed contracts with an agency, you're going to have to spend time doing the workshop. You You're going to have to spend time reviewing designs contributing, getting involved in in the project in terms of design, which again, has cost attached to it in terms of time. And then finally, there's the actual development phase, which includes obviously, having to get involved in making sure that the features are all included that you know, the project on on time, it's, it's aligned with the scope, the integrations are going to work if they're not what the solution you're going to find, sorting out teething problems. And again, that takes time. So a replatform project has the byproduct that it is very time intensive. And that's not always been an obvious factor when determining whether to replatform or not. Now if you're if you're lucky to have an e commerce team that can be allocated to the whole project, fantastic. If you don't, and it's you know, the people that are actually running the business that also have to get involved, that's when things start to get quite tricky. Because you need to make sure that you know, you're you're involved in the project, you feel like you are in control and you're being guided in the in the right way. And that you're managing the resources as best as you can. So that's just kind of a little byproduct of replatform, that a lot of people sometimes miss or, or underestimate. they underestimate their involvement, or they underestimate how heavy it's going to be on those resources. It doesn't have to be like that the way to ensure that a project runs efficiently and you are not wasting time because time is a commodity that none of us can kind of get back is to have a good plan. And a migration plan is absolutely key to a successful replatforming project. Well, let's stress the topic of good planning, and actually is the base for any of the topic we have faced until now. But the case of replac forming is the perfect example. I think that the bad planning in our project of replac forming can lead to really severe consequences, as we already listed before, planning replac forming is to be really deeply analysed first starting from which is the reason why you are reap lat forming, maybe your legacy system has reached the end of the rope. And then you need something fresh, something new, or just you want to make a fresh start with your commercial objectives. Or maybe the replatforming it was already planned before but for different reasons. So it's always better to go through to the scope and see if still, all the requirements are valid, and which are really needed prioritising which are the master feature. And trying to scale the development maybe after the first migration in when you talk about prioritisation is scope actually one of the other byproducts of a replatform. And this is more of think at the beginning, but it can run through is kind of internal expectations and requirements. So if you kind of break down an e commerce operation, obviously, you've got, you know, kind of marketing, you've got sales, you've got logistics, you've got, you know, kind of warehousing, and I don't think there's any solution out there that is seamless. For all of those departments, you know, every department is going to have a, you know, a bit of friction, or just, you know, some things that don't work exactly as they would like specific requirements. Exactly. And so I think oftentimes, when, you know, the kind of subject of replatforming comes up, people think, great, I've got us an opportunity to solve my problems. Now, the reality is that there is still no one size fits all solution. Well, I guess there could be a few built, you know, a custom solution that will cost, you know, a hell of a lot of money and will take a lot of time. But, you know, you have to be pragmatic and realistic and expectations, and you have to manage those because everyone's going to be vying for their own department, everyone's gonna be pushing for their solution, or rather, their problem to be fixed to be solved. And it's not going to happen like that. So internal politics is also something that has to be managed. And the way to do that, apart from the workshop, is to make sure that the project stays on scope, and everyone understands the scope, what you want to avoid is at the end of the product project, when you're measuring that success when you're talking about, you know, kind of goals that you've met, and so on, people are saying, Well, you know, it doesn't do this or what about that particular thing or you know, it still doesn't solve my problem. Those need to be nipped in the bud at the beginning. And you know, that there can be some difficult conversations. I don't like having them. We can't we can tell you know, you have to tell somebody, it can't be done. But unfortunately, that's that's just the reality really, you know, we work as much as we can to find solutions. But if a budget constraints it then you can't do that and you know, not everyone's going to be satisfied. So that's another thing that that is really important when managing a replatform you can always go for that MVP minimum product and then try to agree with the requirements and the requests for the other departments later on, of course, not leaving them, just without functionalities, maybe a bit of more handwork at the very beginning, but after you can always solve all the issues. I guess it Yeah, I mean, I guess it depends on the urgency of the product of the project. And I'm a firm believer in Mbps. But from a merchants perspective, it's a step back. So, you know, we we, we often mean, we've had projects before where, you know, we've recommended an MVP, so that there is no time to kind of adjust to the new platform and then look at scaling up, but you know, some merchants want to go all in, and that's fine, you know, we can accommodate that. But MVP is just, you know, slightly less risky way of doing things, I think, certainly, you know, from when you're when you're changing technology, and you've got to learn everything, you know, you've got to feel like you're in control of there's too many changes, it can make, you know, make people feel overwhelmed and out of control, and ultimately out that the lack of control is what leads to stress, and friction. Yeah, it's always the feeling like going for a step back. But if you look at athletes, the jumpers, they always do some steps back to have a higher jump. So this will be a good metaphor for this situation. Sometimes, you need to take the approach of scaling back in order to scale up. So you know, it's okay to just take a short term pain for long term game, because at least that way, you know, it is it is back control, I think that's one of the most important elements within a replatform is control. That, you know, we are all in control of the migration. Seems everything is a negative, but just before passing to the benefits of Rico forming, can we just go through the risk during the reap lat form? Yeah, I mean, probably the most important element, the risks. So ultimately, when we are migrating one of them, the biggest, I guess, visible elements is data. So we are transferring data from one platform to another. Nowadays, I think it's changed certainly last few years, a lot of merchants wants to migrate, kind of historical data, such as orders, taken on the platform, customer data. And we need to make sure that when that information is migrated over, it's done in a way, which has that kind of seamless effect for when the client accesses the new website on the new platform for the first time, What you don't want is for them to log in, and they got someone else's order information or their data is incorrect. And, you know, that can then have a consequence in terms of confidence, because people think there's a data breach or there's been a hack, and they lose trust. So it's really important for data migration aspect, that that is done in a tried and tested wait. So when, you know, a good way of doing kind of a data migration is obviously do it in, in batches, because you also have an opportunity to cleanse data when it comes to that. So if you do it in batches, so you know, out of 100% of your day to take the first 10% and then you cleanse that it's really important to as a good practice to try some test migration at the very beginning, cleansing the data, retry another testing, migration, and then all the after, you're sure that all the information are in place running your first full migration. Yeah, so you know, the data is really, really important. Because also, especially because you know, a lot of data migration is automated, it's important that it's mapped correctly. And that's where the test migrations kind of work really well. So you do them in batches, and you Alicia can kind of ring fence, any errors. If the first batch goes through fine, great. The second batch goes through fine, great if the third one's got a problem, you're not starting from scratch, you know, you're kind of you're only you're only kind of ring fencing that third block and fixing what needs to be fixed. And another important point is a thorough analysis of the data before starting benchmarking, starting migrating data and fine tuning them. Because you can have different kinds of products that have different and particular features. So not always the same set of information can be used as a framework for all the products. No, and and also, you know, don't forget, if you're working with different technologies, that the technology the way that the data is stored in different technologies varies as well. So you know, if you've got, for example, certain fields within one platform that needs to be migrated over maybe where that data is migrated to, isn't to, you know, the same field that it was in in the press for maybe have to use custom fields or repurpose in other fields. So making sure that the data mapping is done correctly. I think it's also important Just to add about being pragmatic in terms of the data, so there is no point migrating the last five or six years of data into the new e commerce platform. I think it's, most merchants do three maximum. You know, there's anything past that is not required. It's legally not required. I don't know if it's legally, I mean, you obviously need to keep records kind of from an accounting system perspective, but I just kind of think, you know, put yourselves in the customers shoes, would they be going back six years for the, you know, how many of the products you were selling six years ago, are you still selling today. So, you know, it just means that the burden on the person doing the migration and the data cleansing is reduced. So it's just one one element to bear in mind, you know, take a really pragmatic approach in terms of your data cleansing. What about technologies and scope alignment? Well, this goes back partly to, you know, internal expectations. But also, it's really important, you don't get scope creep, because it may be that for a particular platform, and the merchant who worked on a merchant who traded on that particular platform, had a feature, which maybe was native. And so they take for granted, that it's going to be native, or achievable in the new platform, and it might not be the case. So it's really important that people understand what they're getting and what they're not getting. And that's one of the ways that again, you can manage the expectations, make sure that the project is deemed a success at launch. And everyone and all the stakeholders know, when the project launches, what they're getting, it's really important to involve key stakeholders, and sometimes few of them, not all of them, because it's going to get too crowded, and too many requests, and the scope is going to become super, super big. So sometimes having the right, the right key stakeholders can help you more. And sometimes even someone that is actually using the actual feature. So you can never perspective or someone that is an experience on it, it's really important to allocate someone with some seniority to the project, who can take the final decision, when there has to be some conflict resolution, or just, you know, decision has to be taken. Because if you have that decision level a bit too low, then everyone's gonna be throwing their hat in the ring, and everyone's gonna be pushing for their requirement, you need to make sure that there's an escalation point. And what that person says goes, see, you needs to have, you know, kind of high board level decision makers that can take the final call. But it's important also involve people that use that particular feature or function on a daily basis, because it's easy to take for granted, as you say, you know, somebody marketing says, Oh, we don't need that feature. But actually, they might not realise that that feature, it would be, would solve so many problems for somebody that works in, you know, finance, or merchandising, or in logistics. And so it's important, you get everybody's input. And if if your agency's not getting you to, if your agency's not speaking to people in all these different areas, then ask them to do that, it's just really important that everyone has their say, because every platform project should only be done every few years, at best. And so really, the decisions you make today could have consequences for years to come. So make sure you involve people from all departments who are involved in the e commerce business. Most of the time, what our clients share with us is friction. And this kind of not easy way out to explain people that changing technology with a new interface and the need for a new integration is going to make their life better and minimising, for example, the handwork but the usual workers are used to you to have this interface to have this functionality. So there is always this kind of repulsion to new features to new interfaces. It's kind of pushback from the actual employees. I think it's also if we kind of talk about pragmatism and managing expectations, I completely support merchants who say, Look, I don't want to take a step back. I, you know, when, when we launched with the new platform, we need to make sure that we are moving forward. And so it's really important when it comes to integrations that aren't natively supported by there's no native integration rather, with an e commerce platform, that those are really carefully kind of understood or mapped out. And again, scoped out individually. Because, again, what might work for the current setup might not work for the new platform and those teething problems only come out kind of, you know, towards you at and at the end which can then further delay the project. So it's really important that the agency understand that so you need to provide them as much information and there's no such thing as stupid questions, just stupid answers, where, you know, you explain to the agency to the systems integrator, whoever's involved the process, that once somebody may be placed an order, the E RP or the automatic payment system, how that works, or the automation or the marketing, all these different kinds of integrations, maybe don't have a native plugin or a native connection, how they work, because what you don't want is to flick the switch and find that actually, orders aren't pulling through or the automation isn't kicking through, or the subscriptions aren't working. So when it comes to kind of teething problems, that's a big risk. And they need to be mitigated by just making sure that you can have sandbox sites that are tested. And that work and speak to also to those platform providers and see if you can kind of be given a you know, kind of a test environment to be able to manage those don't take for granted that because maybe they're API LED, or that you know that there is some kind of plugin that is going to work seamlessly, because we've seen it before we know the connections were pulled through, you know, orders are downloading, but then actually, it starts to build up in terms of the data flow, and the API's slow down or they fail, or they you know, that they they get blocked and throttle. So it's, you know, it's really important that to make sure that the teething problems are mitigated, and they're tested, tested and tested thoroughly, again, not to forget, which is the impact of SEO, when you want replatforming. They change related, the risk related to the changes in the URL. Yeah, I mean, there's, I don't think there's any risk that is number one, I think they are all equally important for the majority of merchants. But SEO is is a big driver, for a lot of merchants organic listings, they take such a long time to build. And in a bad migration can be lost, like literally overnight. And so SEO, you should be guided in terms of SEO from the agency, because what's going to happen is when you replatform, you may change the content on a page, you may change the design and layout of a page. But you will certainly be changing the code of the page and possibly the URL structure as well. And all these benefits, you know, you may improve the content, you may improve the layout, you may you may improve the page code, and you may improve the URL. But there are changes that are going to affect the ranking. Because when when the search engines access your website to recrawl them, they will see there's been changes and therefore they will reevaluate that particular page. And it will have an effect nine times out of 10. Those effects are short term, they tend to go up or down a couple of positions, possibly a couple of pages, but normally they kind of get back up within a fairly short timeframe. But it you know if it goes wrong, you could lose your rankings that you've worked very hard on for years, in a matter of days. So it's really important that you do things like 301 redirects. So you know, if you are changing URLs, you need to make sure that you map the old URL to a new one was using what's known as a 301 redirect, which basically, when you go into the old page, it automatically directed to the new one. And accordingly, when Google tries to access the old URL, it's being told this is now the new one, and it will update its database. So in terms of SEO, just make sure that your agency has a plan for that. And also just you have to be very thorough, so the agency needs to be thorough, but also there is a responsibility from the customer, from the merchant, to make sure that they tell the client everything. So we had a case once where the ecommerce was on one platform, and the blog was on another. We weren't told. And you know, we were told it's all on within the one domain and you know, within the one thing, fair enough. And actually, when it came to re platforming, it was only when we were kind of doing the initial kind of scoping, we found out that there were these two different platforms, and we'd actually have to replatform the second platform as well. So you know, had we not done that, then that blog would have disappeared. And so you know, there are many factors in terms of SEO. And the only the only reaction when you lose rankings, and when the SEO is affected in a negative way, is anger and frustration, both from the agency and the merchant. So to avoid those, just make sure that the SEO migration is is top notch as well. So the faster the better, the faster you can go live again, the faster you can restart, you're building your ranking and building your SEO presence. It's important to it. I don't know if it's a benefit in terms of that speed. I would say more than anything, you just have to maintain the control. There's if you try to rush it, you can still achieve that. But you have to have that control. You have to have that plan. You need to know what's happening. What each, you know party's doing, and that nothing's been left behind. So, you know, and in terms of how to mitigate the SEO changes, again, it's 301 redirects, might it be worth making changes to content after launch, so that you're not changing too many factors, you know, we've recommended that before, just you know, the priority has to be we are changing to another platform, the priority of we are changing content can wait, in my opinion, because unless it's wrong, in which case, you change it before the replatform, you need to just, you know, kind of prioritise and say, right, let's not overwhelm these changes, let's just make sure that the waters are fairly clear, before we make more changes, because if you try to do too much, and there's a problem, you're sifting through a lot of work to see where that problem arose from. Whereas if you kind of ring fence these things again, same, right. So with the launch, we're going to migrate the data as is and change the platform and the design, great, then after that, we're going to re, we're going to change the URLs, fine, do that, then after that, we're going to change the content, fine, do that then, so you've got this kind of cascading element where you're able to just do things in blocks, maybe in Sprint's even, but at least that way you maintain the control. So that's one way that you, you can kind of achieve the speed, if you like, just prioritising what you're, you know, kind of what your goals are, the goal is to replatform to another, yeah, to another platform. And finally, let's talk about what good is in replatforming, which are the benefits. Well, I guess, you know, that's subjective, because you need to know why you're replac forming in the first place. But the main kind of benefits most of the reasons why merchants replatforming, therefore, the benefits of it, often stem around functionality. So you know, by replatform, to another ecommerce service provider, they're able to maybe get some more functionality, possibly that would be available with the current platform, but might cost more to implement. And one that we hear quite often, and especially in with the advent of SAS, is a reduction in costs. So if you were on a self hosted deployment, you would responsible for all the updates, all the upgrades, all the security patches, PCI compliance, all these different elements. And they are cost because you may have to involve a developer, you may have to hire a developer, whether that's in house or out, outsourced, and obviously, to maybe buy the actual, you know, kind of patches or modules or plugins. So you save that sometimes if you migrate to a platform, that is SAS, or maybe has a lot of these, you know, kind of features included, as there's none of the production costs, because you're not paying maybe for infrastructure, you're not paying for additional features, and you're not paying for the resources to implement and or maintain those particular Configure. It's not said that there's a reduction in costs, you know, if you're moving from self hosted to SAS, you may find that you're actually paying more because your turnover is higher, but hopefully, there's some benefits that will actually make that an investment. So if you're gone from spending 100 pounds a month to 300 pounds a month, there's a that's an investment, and you should reap a benefit of sorts from from that investment. And finally, there's kind of an improved customer journey. So you've got to remember that ecommerce is constantly evolving. And you only have to look, you know, some websites that you would that you would say to yourself, this is dated now, whether that's a design, or whether it's the fact that you've got to jump through so many hoops to actually be able to check out. So the benefits is, you know, you can apply a new design, take advantage of new features, and new by trends. And, you know, kind of in essence, offer your visitors an improved customer journey, and user experience, which hopefully will lead to an increase in sales and, you know, make the replatform, therefore, positive investment. But this also then kind of overlaps a bit in terms of when selecting a platform. Because what you need to if we go back to our first point about, you know, the byproducts of replatform, it is time replatforming project is very, very time consuming. And so when you're evaluating platforms, even if you're just starting out, you want to just future proof as much as possible. So there are platforms out there that are great for startups, but if you've got a product or if you've got ambitious growth plans, that that particular platform may have a glass ceiling, it may not work over X amount of you know, thousands of visitors a week, it may not work very well over a certain you know, gmv you know, annual monthly revenue threshold So you kind of need to ask yourself saying, you know, how long is this platform going to last me? Is it gonna last me two years based on my forecast? Right? What are there any alternatives out there that can last me five years, and they might cost you a bit more today, they might cost you the same, but at least you're not going to be having a replatform conversation sooner than you actually need to. So just make sure that you know, you kind of evaluate and do some research and see if you know, if there is a scalability that you need those glass ceilings as I refer to them, but also look at market trends. So if you look at bigcommerce, and Shopify and other SaaS platforms, you know, five years ago, seven years ago, it was when you spoke about SAS, it was it was restrictive, that's it correlated with restriction, or you can't do much on SAS, because it's a closed code, you can't access the source code and all this stuff. Nowadays, it's really becoming normal, very acceptable. And in fact, you know, kind of maybe very advantageous for a lot of big brands that are harnessing it now to use assess ecommerce platform. So also have a look at the market trends. You know, if it's moving towards SAS, do you really need an on prem, self hosted platform? Or is SAS actually the answer that you're looking for? You know, how easy is it to add plugins to improve the functionality to increase the features. And, you know, again, cost it over the course of five years. So you know, in terms of, of how to reduce the requirement for replatform, as you grow, it's making sure that the platforms can give you the longevity and support you in your growth and not actually hold you back. And stop you progressing until you move to another platform in two to three years time. Great. I think that's it for this episode. I'm really glad that we reached already the fourth episode and, and we apologise for our audience for the information we're sharing with them. We had a lot of feedbacks. And I wanted to thank everyone for this. Yeah, and also, you know, if I just want to go back and quickly say about this episode, it was replatforming is not something to be taken lightly. It's not really something that you can kind of throw into a quick podcast episode, it is imperative that you plan and scope out a replatforming project very, very well. If you if you've enjoyed this episode, you know, please share it with others share with people that you feel could benefit from it. You can also leave reviews on all the major podcast platforms. And you know, make sure you visit our website and follow us on social media. Feel free to contact us if you want to go deeper on this topic. You have all of our contact and see you for the next episode.