Launch HN: Hotswap (YC S21) – Easily migrate customers away from competitors
162 comments
How do you deal with data loss if there isn’t a perfect match between the data models? For example, if I’m looking to migrate from GSuite to Microsoft Office365 (or vice versa) and there’s not a 1:1 mapping. Or if the behavior of the same spreadsheet formula is slightly importantly different? These are complicated examples obviously and maybe you’re not tackling them yet, but I think I see (at least as an external observer with limited visibility) a lot of the internal teams really focusing on those corner cases where the data loss path and other migration challenges rather than the happy easy-to-automate piece.
Similarly, how do you see this service scaling beyond a boutique consultancy or outside of a handful of cases where it’s easy? If you’re successful, do you think vendors won’t do everything to make your access more difficult or cut you off completely? If you see it more as a “we force the vendors we integrate to sign a mutual agreement” kind of strategy, how do you see yourselves not becoming a gate keeper and velocity bottleneck for feature development (ie company wants to roll out feature X and now they need to involve you first so that you can write migrations to …?)
It’s an interesting idea so curious to hear your thoughts about the challenges.
Similarly, how do you see this service scaling beyond a boutique consultancy or outside of a handful of cases where it’s easy? If you’re successful, do you think vendors won’t do everything to make your access more difficult or cut you off completely? If you see it more as a “we force the vendors we integrate to sign a mutual agreement” kind of strategy, how do you see yourselves not becoming a gate keeper and velocity bottleneck for feature development (ie company wants to roll out feature X and now they need to involve you first so that you can write migrations to …?)
It’s an interesting idea so curious to hear your thoughts about the challenges.
This is a good question, and, frankly, the hardest part of our business. We do the work of mapping data, understanding the corner cases, and implementing translations that yield the same results. This is easier when vendors work with us, since they help us with that mapping (and in some cases make changes to their product in order to accommodate.)
That said, if your new platform simply doesn't support the old features, then there isn't much we can do, except for provide you a backup of the original data.
We think that end-users ultimately want a choice in the vendors they use. Our mission is to facilitate that, and if a user wants to move to a new platform then they'll ultimately find a way to do it.
To that end, we see ourselves as a "Switzerland", much like Plaid and Zapier are able to integrate across many competing products. We don't think we'd stand in the way of companies creating new features. If they want to be able to onboard users from competing platforms, then we think we can make that easier!
That said, if your new platform simply doesn't support the old features, then there isn't much we can do, except for provide you a backup of the original data.
We think that end-users ultimately want a choice in the vendors they use. Our mission is to facilitate that, and if a user wants to move to a new platform then they'll ultimately find a way to do it.
To that end, we see ourselves as a "Switzerland", much like Plaid and Zapier are able to integrate across many competing products. We don't think we'd stand in the way of companies creating new features. If they want to be able to onboard users from competing platforms, then we think we can make that easier!
Amazing product idea, solves a real need. My biggest concern would just be remembering you all exist when needed since this really is not a 'category' so to speak.
Anyway just wanted to chime in that "Switcherland" would have been a funny name given your sensical positioning as neutral. Current name is great though! "Bringing Switcherland in to facilitate" is just something I'd love to say at the office.
Anyway just wanted to chime in that "Switcherland" would have been a funny name given your sensical positioning as neutral. Current name is great though! "Bringing Switcherland in to facilitate" is just something I'd love to say at the office.
How does this figure into unit economics, in terms of limiting the cost involved in mapping data which is more consultancy (based off your BI use case and per dashboard pricing), migrations by nature tend to be one-off and not really a source of recurring revenue. Curious how to bridge the gap between what you have now to a Plaid/Zapier model, a tough problem no doubt!
Also, I may be misunderstanding your current offering.
Also, I may be misunderstanding your current offering.
[deleted]
Just want to say, love your username. (I give it a C+.)
It's rare that an idea like this comes along. If you can pull it off, it's one of those ideas that are obvious in hindsight. Good luck!
It's rare that an idea like this comes along. If you can pull it off, it's one of those ideas that are obvious in hindsight. Good luck!
This is a really great question. It's not an insurmountable problem, but the compromises need to be understood.
Further, there are lots of things that can be done on the receiver side to smooth out the experience. It is frustrating for customers when a product hasn't thought about how imported content will perform. Often you are left with problems like any edits to the import needing additional fields completed to edit (possibly a significant cost per edit), content can't be fully rendered so appears as an HTML blob in a field, imported data can't be filtered so you can't easily hire someone to fix it without fishing through other data etc.
If you are entering a mature market then importing a competitor's content in a streamlined fashion is a great way to gain adoption and lock in customers. Some markets have lots of competition so you can possibly only target smooth migration of a subset. It shouldn't be an afterthought.
Further, there are lots of things that can be done on the receiver side to smooth out the experience. It is frustrating for customers when a product hasn't thought about how imported content will perform. Often you are left with problems like any edits to the import needing additional fields completed to edit (possibly a significant cost per edit), content can't be fully rendered so appears as an HTML blob in a field, imported data can't be filtered so you can't easily hire someone to fix it without fishing through other data etc.
If you are entering a mature market then importing a competitor's content in a streamlined fashion is a great way to gain adoption and lock in customers. Some markets have lots of competition so you can possibly only target smooth migration of a subset. It shouldn't be an afterthought.
> If you’re successful, do you think vendors won’t do everything to make your access more difficult or cut you off completely?
Vendors should want their schema available for import by new customers. That seems like it should be a good guide for exporting data. As for making export harder, companies will just demand their data and then the vendors will have to do the export; vendors won't be able to keep the data (in almost all cases of companies that have a contract.)
Vendors should want their schema available for import by new customers. That seems like it should be a good guide for exporting data. As for making export harder, companies will just demand their data and then the vendors will have to do the export; vendors won't be able to keep the data (in almost all cases of companies that have a contract.)
Wix is an interesting choice. I remember during the recent feud between Matt Mullenweg (Wordpress founder) and Avishai Abrahami (Wix CEO), Matt said this:
"They are so insecure that they are also the only website creator I’m aware of that doesn’t allow you to export your content, so they’re like a roach motel where you can check in but never check out."
So I guess there's probably demand for a nice export tool there.
"They are so insecure that they are also the only website creator I’m aware of that doesn’t allow you to export your content, so they’re like a roach motel where you can check in but never check out."
So I guess there's probably demand for a nice export tool there.
Wix gave my personal contact information to a literal criminal (as in someone who physically attacks people) after I reported him to Wix for scamming on their platform. I still have a copy of the voicemail where he was yelling that he's "going to find [me] and kill [me]."
Their support basically told me to fuck off when I asked why on earth they gave him my details, and the CEO just ignored me.
Great company.
Their support basically told me to fuck off when I asked why on earth they gave him my details, and the CEO just ignored me.
Great company.
I hadn't seen that. I personally don't have any problems with Wix as a platform, and if people want to use it, then that is great!
But I do think that customers ought to be able to have a choice in the vendors they use. They should be able to choose the right platform for their needs, which will change over time. We want to help facilitate that.
But I do think that customers ought to be able to have a choice in the vendors they use. They should be able to choose the right platform for their needs, which will change over time. We want to help facilitate that.
I just so happened to be reading the Wix developer agreement today and they explicitly disallow using their API if your primary purpose is to migrate users off of Wix. So that's nice.
Insecurity is indeed a good way to describe it, then.
> if people want to use it, then that is great!
No it's not! Most people using Wix have no idea they will ever NEED to export their data. Call it user ignorance.
No it's not! Most people using Wix have no idea they will ever NEED to export their data. Call it user ignorance.
Under European law, Wix HAS to offer a data export tool. I mean it may not be usable to rebuild a website quickly, but at least you should be able to get your content out in some format or other.
If you are referring to GDPR then it apply to personal information, not all types of data. I don't think content in a CMS would be considered PII, thus not required to be exported. GDPR export is meant to give customers a way to see what PII is stored, not as a way to export all types of data.
No. That's incorrect on both counts. That is neither the intent of Article 20 nor the type of data it concerns.
https://gdpr-info.eu/art-20-gdpr/ reads
> 1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller [..]
https://gdpr-info.eu/art-4-gdpr/ reads
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); [..]
https://gdpr-info.eu/art-20-gdpr/ reads
> 1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller [..]
https://gdpr-info.eu/art-4-gdpr/ reads
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); [..]
This is a completely incorrect interpretation of the concept of “personal data”. This is about information _concerning_ an identifiable person. See recital 26, https://gdpr-info.eu/recitals/no-26/
> ‘personal data’ means any information relating to an identified or identifiable natural person
Exactly. Content in your website is not information relating to an identified or identifiable natural person. GDPR does not require a company to provide export of website content. It does have a requirement to export data they have stored about you though.
Exactly. Content in your website is not information relating to an identified or identifiable natural person. GDPR does not require a company to provide export of website content. It does have a requirement to export data they have stored about you though.
Not a lawyer, but my business doesn't sound like a identifiable natural person...
It is not. If you're using some service as a business, you may be out of luck.
If however your customers are natural persons, you can migrate their data from a competitor (with their help and/or agreement).
Helping with the latter appears to be the point of Hotswap.
If however your customers are natural persons, you can migrate their data from a competitor (with their help and/or agreement).
Helping with the latter appears to be the point of Hotswap.
I beg to differ. There is almost no legal business with paying customers that wouldn’t fit under these criteria
It looks like they make it complicated by only offering export of "collections" to csv format. So you have to export every collection in a site. Which doesn't seem to export things like images.
That’s not compliant with GDPR, then.
They seem to think it is: https://support.wix.com/en/article/gdpr-deleting-and-restori...
(Not disputing your assessment myself)
(Not disputing your assessment myself)
If you're a Wix user covered by GDPR, you can follow the below instructions to file a complaint if, in your opinion, the support Wix is providing to export your data does not meet GDPR's data portability guidelines.
https://noyb.eu/en/exercise-your-rights-article-20-transfer-...
https://noyb.eu/en/exercise-your-rights-article-20-transfer-...
Wix! Take note! Some guy on the internet says you are legally obligated to provide data export!
[deleted]
I have a $100M SaaS in a different space but the underlying tech is identical. I had this idea ~10 yrs ago when we first started writing our own import logic to move users over from competing services.
The engineering challenges to make this work flawlessly is going to be substantial to say the least. I GET from ~70 data sources right now...I couldn't imagine having to GET,POST, CHECKPOINT and DIFF with all the edge cases that appear.
Best of luck but this is a very hard problem to solve. Would love to see someone see this through!
The engineering challenges to make this work flawlessly is going to be substantial to say the least. I GET from ~70 data sources right now...I couldn't imagine having to GET,POST, CHECKPOINT and DIFF with all the edge cases that appear.
Best of luck but this is a very hard problem to solve. Would love to see someone see this through!
It's not even the technical challenge that is the big issue. It's the political one. Trying to get vendors to provide API access to migrate data away on a scalable solution will be a no-go for most of them.
Co-founder here. We skip the politics because we're willing to scrape to export or import if APIs aren't available on either end. That allows us to function independently of vendor buy-in.
This assumes the incentive is balanced for the vendor, that they'll win as much business (or more) than they'll lose.
I don't believe this is true anywhere, but specifically those vendors who are most aggressive about creating walled gardens and who have high revenues with unhappy customers looking to leave are both the sweetest spot for your end user demand and vendor resistance.
I suspect that you hope to leave those vendors (when discovered) until later, once you have momentum. But I also suspect that these will be the ones end users demand very early on and that end user perception of usefulness of your service is linked to the difficult vendors.
Additionally you have a time and opportunity window problem. Changing vendors isn't core to the business of most companies, and instead it's usually the product of a concern at a point in time (i.e. costs this year) that comes with limited window in which to execute on the project (i.e. we'll only distract ourselves from our core business for the next 6 months to try and reduce costs, then it's back to core business). This is going to make end user acquisition harder (more expensive) for you than most startups as you're going to have to invest more in the marketing to ensure you're on their radar at that point in time (with the assumption you can execute within the window of opportunity).
I'm not down on your business, like others in this thread this is a thing I've touched at the peripherary of my career and I'm just sharing my thoughts. You've picked a hard problem and if solved it definitely has value.
I don't believe this is true anywhere, but specifically those vendors who are most aggressive about creating walled gardens and who have high revenues with unhappy customers looking to leave are both the sweetest spot for your end user demand and vendor resistance.
I suspect that you hope to leave those vendors (when discovered) until later, once you have momentum. But I also suspect that these will be the ones end users demand very early on and that end user perception of usefulness of your service is linked to the difficult vendors.
Additionally you have a time and opportunity window problem. Changing vendors isn't core to the business of most companies, and instead it's usually the product of a concern at a point in time (i.e. costs this year) that comes with limited window in which to execute on the project (i.e. we'll only distract ourselves from our core business for the next 6 months to try and reduce costs, then it's back to core business). This is going to make end user acquisition harder (more expensive) for you than most startups as you're going to have to invest more in the marketing to ensure you're on their radar at that point in time (with the assumption you can execute within the window of opportunity).
I'm not down on your business, like others in this thread this is a thing I've touched at the peripherary of my career and I'm just sharing my thoughts. You've picked a hard problem and if solved it definitely has value.
Honestly if I were OP I would specialize in a certain industry, ie healthcare, manufacturing, apparel, auto, or similar. Then get familiar with the big software systems all these people use. Systems like Epic and ERP systems in general take companies hundreds of millions of dollars to migrate from and to. If their company can automate even a little bit of this, that would be very lucrative.
So if there's no API then you can't help them unless their data is public?
Presumably if a user’s data is visible in any way while logged in as that user, they can scrape it.
That’s correct
I was in such a business decades back as a consultant, migrating clients from incredibly expensive mainframe systems to much more affordable alternatives, and I found out the path is fraught with perils. I was an independent consultant doing this sort of thing to get companies out of software contracts that would be around $10 million per annum in today's bucks. The vendor who was losing the clients had revenue approaching $billion/annum in today's bucks, ie a few thousands of times my revenue. I got a letter from their lawyers, an ultra-aggressive firm that had been written up in the NY Times for being so efficient at winning ultra-aggressive lawsuits. I took it to my lawyer, the best I could afford, and he negotiated a total surrender, which meant perhaps half of my potential clients were now off-limits. I did pretty well with the other half for around 10 more years, but the vendors whom I was helping by guiding their new customers through the inexplicable aspects of the replacement software, came to want my revenue and to prefer that their customers not be too well informed about what they were getting into, so they started putting terms into their software licenses that required new customers to fence me out. Game over.
I went back to work as a developer for a vendor earning huge profits in a different vertical market which they dominated. Their lawyers were far more strategically important than their development team. The amount of revenue they derived from capturing customers was audaciously incredible for a firm operating in so-called free-market economies, even though they were always up to their elbows in legal battles and skirmishes on multiple fronts over who owned what and who was allowed to use which licensed API's for what functions.
I went back to work as a developer for a vendor earning huge profits in a different vertical market which they dominated. Their lawyers were far more strategically important than their development team. The amount of revenue they derived from capturing customers was audaciously incredible for a firm operating in so-called free-market economies, even though they were always up to their elbows in legal battles and skirmishes on multiple fronts over who owned what and who was allowed to use which licensed API's for what functions.
I feel like there's a deep learning (possibly computer vision) route to this that would be extremely hard to create but would be able to arbitrage 90% of the difficulty with updating for new UIs or handling edge cases. Had you ever pursued that route or seen things that tried?
I really don't understand your usage of the word arbitrage here. Also computer vision is related to images specifically - how is that even relevant here?
This guy can speak for himself but I've read the comment a few times and I would surmise there's some ESL word-soup happening here. I am going to hazard what he's getting at is using CV to import data from one UI possibly into another. I think to get around the lack of a lack of API support. Similar to the effect a company might use OCR software to migrate data from paper forms a CRM, or something? I'm still wondering why I honed in on this one comment, but hey you felt intrigued enough to leave a comment too, so there must be something to it.
What does ESL mean? I can't seem to infer it
English as a Second Language
English as a second language I presume
English as a Second Language
One of the products I support became the leader in our niche, partially because we offered data migrations for free. I was the strongest dev in this area - not that I'm any better overall than the others, this is just one of my strengths, but I ended up doing almost all the migration work.
Through the years of doing that, I ended up in a similar place to this whole idea - I had specific migration scripts for each competitor, which I'd run when someone moved over to us. Some of them were easy, some of them involved parsing data and metadata to determine the customizations made on other platforms, and then generated scripts that would work for specific customers instances.
All that to say, I get where you are going with this idea.
I don't have any particular advice or feedback, as this kind of work really is all about problem solving when you get a new data source. But I do think you are setting yourselves up for enjoyable work - the easy jobs give you satisfaction in getting things done, and the hard jobs give a different kind of satisfaction in figuring out tough challenges.
Good luck!
Through the years of doing that, I ended up in a similar place to this whole idea - I had specific migration scripts for each competitor, which I'd run when someone moved over to us. Some of them were easy, some of them involved parsing data and metadata to determine the customizations made on other platforms, and then generated scripts that would work for specific customers instances.
All that to say, I get where you are going with this idea.
I don't have any particular advice or feedback, as this kind of work really is all about problem solving when you get a new data source. But I do think you are setting yourselves up for enjoyable work - the easy jobs give you satisfaction in getting things done, and the hard jobs give a different kind of satisfaction in figuring out tough challenges.
Good luck!
My initial reaction is that this feels brittle (because people are incentivized to break it) and and hard to scale, but thinking about it more, it might be more scalable than I'd thought -- e.g., I'll only migrate from Chartio to Sisence once, but Sisence may want to use this service for hundreds of incoming customers.
That said, you'll likely only have a handle of repeat customers for each integration. A couple of Chartio's competitors will want the Chartio integration. A couple of Wix's competitors will want the Wix integration.
(And if Chartio is shutting down, that integration is only useful for a brief period of time, but it could be extremely popular for that short period of time.)
You'll definitely build up expertise in exfiltrating data, and develop as a collection of internal(?) tools to make it easier. I'm just curious if that's enough to make building new integrations cost-effective.
Zapier has a similar limitation and has managed to succeed, but they're more generalized, whereas this is a single use case for each service. I feel like this makes the most sense as a high-end "We build custom migration solutions" service. (Rereading your post, that might align with how you're treating it.)
I hope I'm wrong about the scalability, though! If y'all can make migrations cheap and easy across a broad range of services, that's hugely beneficial to users. It's unfortunate that every service benefits from having a moat. Every user will benefit from the bridges you're building. Best of luck!
That said, you'll likely only have a handle of repeat customers for each integration. A couple of Chartio's competitors will want the Chartio integration. A couple of Wix's competitors will want the Wix integration.
(And if Chartio is shutting down, that integration is only useful for a brief period of time, but it could be extremely popular for that short period of time.)
You'll definitely build up expertise in exfiltrating data, and develop as a collection of internal(?) tools to make it easier. I'm just curious if that's enough to make building new integrations cost-effective.
Zapier has a similar limitation and has managed to succeed, but they're more generalized, whereas this is a single use case for each service. I feel like this makes the most sense as a high-end "We build custom migration solutions" service. (Rereading your post, that might align with how you're treating it.)
I hope I'm wrong about the scalability, though! If y'all can make migrations cheap and easy across a broad range of services, that's hugely beneficial to users. It's unfortunate that every service benefits from having a moat. Every user will benefit from the bridges you're building. Best of luck!
Love this idea. Some quick thoughts:
1) Tool to tool choices: Many migrations involve making decisions that are judgement calls because of service inconsistency (e.g the security roles in the two systems aren't exactly the same so you have to evaluate tradeoffs in how to handle in the new one). I bet many of these 'decision points' could be a defined for particular migrations, allowing the destination service to present to their customer options with tradeoffs, and then automate the migration from there. Even more valuable than the data flowing would be being the central tool that knows about these 'choice-points' in specific migrations.
2) White labeling: a lot of B2B SaaS companies would love to offer migration services. I would have paid $ per migration for something like this if it worked.
3) Services work as needed: I still think many migrations custom work is needed. I would lean into this actually if I were you. We would have loved a trusted 3rd party that just wanted to do migrations. It was hard to get incentives aligned, though, with many systems integrators because they obviously wanted a direct relationship with the customer & hoped to sell them more stuff afterwards. If B2B companies trusted this was your specific focus you could be a better 'full service' partner across both what can be automated and what can't be.
1) Tool to tool choices: Many migrations involve making decisions that are judgement calls because of service inconsistency (e.g the security roles in the two systems aren't exactly the same so you have to evaluate tradeoffs in how to handle in the new one). I bet many of these 'decision points' could be a defined for particular migrations, allowing the destination service to present to their customer options with tradeoffs, and then automate the migration from there. Even more valuable than the data flowing would be being the central tool that knows about these 'choice-points' in specific migrations.
2) White labeling: a lot of B2B SaaS companies would love to offer migration services. I would have paid $ per migration for something like this if it worked.
3) Services work as needed: I still think many migrations custom work is needed. I would lean into this actually if I were you. We would have loved a trusted 3rd party that just wanted to do migrations. It was hard to get incentives aligned, though, with many systems integrators because they obviously wanted a direct relationship with the customer & hoped to sell them more stuff afterwards. If B2B companies trusted this was your specific focus you could be a better 'full service' partner across both what can be automated and what can't be.
I love it. It’s like hiring a professional moving company for a cross-country relocation. Nobody expects it to be cheap. I’m curious how you will go able moving sensitive data. If you can figure out the HIPPA thing there is giant, constant money in moving EMR systems. CRM seems like a fairly obvious place to start. Consider targeting “vendor vs vendor” keywords to find people at the top of the migration funnel and become a key part of their plans. Best of luck to you!
That's a great analogy and SEO recommendation! We haven't touched EMRs yet, but those difficult migrations are in our wheelhouse.
re: sensitive data - we provide an on-prem solution when an NDA or our TOS is insufficient
re: sensitive data - we provide an on-prem solution when an NDA or our TOS is insufficient
Awesome stuff. I wasn’t clear if you were targeting SaaS companies as the customer or their end users, but in either case it would be an interesting exercise in data gathering to advertise in order to sense where the demand is. Alternatively Google Trends may have some good data directionally on “vendor to vendor migration” type terms.
Gauging demand would certainly help us prioritize. We primarily target vendors who want to acquire customers, as they have a consistent need for migrations. That said, we also help end-users migrate to vendors we don't have relationships with. Finding end-users who are migrating requires excellent timing, so we're open to SEO strategies.
I've experienced firsthand the power of lock-in that bloated, monolithic EMR and PMS (practice management systems). There is an entity parallel to Hotswap, Bridge Connector, focused on offering different forms of migrations and integration in the medical space.
Funny, this prompted me to look them up, and it seems they spent their $25m B round and gave up last year.
Good luck OP, particularly if you ever approach the healthcare industry.
Funny, this prompted me to look them up, and it seems they spent their $25m B round and gave up last year.
Good luck OP, particularly if you ever approach the healthcare industry.
I agree, this is brilliant. What's wonderful is that customers can see the price before spending it. That's not the case for the two competitors (internal work and consultants). That makes worth-the-money analysis actually reasonable.
As someone who's considered becoming a customer of certain platforms, I've hesitated because of the worry that the data would be "locked in", making it difficult to transition if I ever wanted (or needed) to.
This is true both as an individual, in terms of services like Gmail, and as a business owner looking at SaaS options such as Circle.so.
There's a lot of risk tied up in not having complete control over one's data. I like that you're working on that problem.
This is true both as an individual, in terms of services like Gmail, and as a business owner looking at SaaS options such as Circle.so.
There's a lot of risk tied up in not having complete control over one's data. I like that you're working on that problem.
but this isn't working on that problem, at least not for individuals. this is providing a way for lock-in ecosystems to pull you in, not a way for you to get out (except to another lock-in service who hired hotswap).
We are actually working on this problem too - stay tuned! There's no reason end-users couldn't use Hotswap to either extract their existing data as a backup, or use us to move to a different platform. After all, the code is the same.
It is true that we have been marketing to vendors. That has been our method for prioritizing which scrapers to write.
It is true that we have been marketing to vendors. That has been our method for prioritizing which scrapers to write.
[deleted]
Here is a question (two questions) - are there particular platforms, or classes of platforms, where you worry about lock-in the most?
And would it be useful for you to have a backup of your data from a SaaS vendor? Or is that not so useful without the subsequent "import" to another?
And would it be useful for you to have a backup of your data from a SaaS vendor? Or is that not so useful without the subsequent "import" to another?
This idea is amazing. You’ll have an infinite money printing machine. Even if you have to do a “hybrid” automation/manual labour model for some customers people will gladly pay.
This takes PG’s advice “do things that don’t scale” to an extreme IMO. The morale of the engineering team will be low, as the most valuable eng work by far will be to trudge through gnarly integrations — either to do new ones or fix the growing number of integrations that are constantly breaking — with low hope for automation.
Today at work we just talked about the problem you‘re solving, funny to see this here.
We maintain a couple of importers for competitor data, most of which are DB dumps or collections of pdfs and images.
We‘d love to have it be somewhat self-serve at some point, but it‘s a difficult problem. It‘s also sensitive data which we don‘t want to handle outside our systems.
To give you a price point idea, we charge about 3k for an initial import, so about the same as we charge for a year of service.
We‘d love to have it be somewhat self-serve at some point, but it‘s a difficult problem. It‘s also sensitive data which we don‘t want to handle outside our systems.
To give you a price point idea, we charge about 3k for an initial import, so about the same as we charge for a year of service.
Thank you for this perspective. Other companies have told us similar things, and we're generally willing to be flexible to help accommodate a security checklist. One easy solution we've talked about with some customers is to ship a docker image which uses their own DB/infra to perform migrations, so that customer data isn't touching our servers.
Do you fear an arms race of sorts if this becomes big? Someone founds StopSwap to randomize APIs?
Co-founder here. There are companies that sell software to prevent bots. It's a cat and mouse, but ultimately a user has to be able to use a product, which has a UI that must appear relatively stable, even if the underlying markup changes.
[deleted]
"There is another theory which states that this has already happened."
I've built so many bespoke crawlers for this exact purpose over the years and I always thought it would be excellent to have a platform purpose built for this - even if it just assisted simple things like authentication/login and object identification in api's/feeds/portals. I would be really curious to see what kind of tooling you guys use internally to build these crawlers. There has to be a better option than headless webkit and xpath querying.
Rent the runway is switching back to UPS (FedEx was really bad) so I hope you manage to sell this back to your old employer!
Ha! The system we built there was something that I'm really proud of - by integrating with both UPS and FedEx (and other couriers), we were able to have instant negotiating leverage if one carrier offered better service levels or pricing. That was one of the inspirations for this business - why can't all companies benefit from this kind of choice?
This is super cool and solves a great need.
What happens if the platform you’re trying to get data out of bans you or throttles you because you’re aiding and abetting them losing customers (maybe it wouldn’t happen since they’d probably be violating an SLA with the client). I would presume some companies have specifically not offered users API access to make sure they are locked in.
Awesome work!
What happens if the platform you’re trying to get data out of bans you or throttles you because you’re aiding and abetting them losing customers (maybe it wouldn’t happen since they’d probably be violating an SLA with the client). I would presume some companies have specifically not offered users API access to make sure they are locked in.
Awesome work!
Thanks for the appreciation! In cases where an API isn't offered, we build scrapers. And while a platform can certainly throttle an export, slow > impossible. As long as a user can use a product, we're confident we can export the data.
As someone who scrapes sites as a hobby..... I can only wish you good luck! ;)
So long as you're small, and aren't either (a) stealing away too many customers or (b) imposing too large a load on the site's resources, you'll probably be fine. But once you get large enough to be noticed, you may have a problem.
So long as you're small, and aren't either (a) stealing away too many customers or (b) imposing too large a load on the site's resources, you'll probably be fine. But once you get large enough to be noticed, you may have a problem.
If your customers are in Europe, GDPR mandates they be able to get their data out (data portability). Services likes this would be wise to lean on regulatory requirements, and report vendors who attempt to prevent customers exporting their data (while encouraging them to support an API for data export).
Congrats on your launch. This is an obvious pain point and challenging to scale to put it lightly. I did have to chuckle a little at this though:
>internal development teams (who end up being stuck doing this kind of work)
I can just imagine your job ads now: "100% of your job is doing the work all developers hate to do!"
>internal development teams (who end up being stuck doing this kind of work)
I can just imagine your job ads now: "100% of your job is doing the work all developers hate to do!"
I think it is ok as a dedicated job.
The reason I hate doing it as an internal dev is because nobody at the company really sees it or appreciates it and it is not part of my goals, it is usually well outside my stack and area (often a lot of time in the DB where I am usually not), and if you are any good at it, you get to be the new support guy for issues with it from now on.
Everything for the migration is also a one off hack so you are not writing good code, but good enough code.
At a prior job, doing well at a migration meant this one dev got stuck doing all the support work.
As a dedicated job, Hotswap would probably want to reuse scripts regularly, making it more like software development and less like console program hacking.
The reason I hate doing it as an internal dev is because nobody at the company really sees it or appreciates it and it is not part of my goals, it is usually well outside my stack and area (often a lot of time in the DB where I am usually not), and if you are any good at it, you get to be the new support guy for issues with it from now on.
Everything for the migration is also a one off hack so you are not writing good code, but good enough code.
At a prior job, doing well at a migration meant this one dev got stuck doing all the support work.
As a dedicated job, Hotswap would probably want to reuse scripts regularly, making it more like software development and less like console program hacking.
I actually enjoy this kind of work. Wonder if they're hiring.
Well almost everyone is hiring all the time, it's just a question of whether you have the skills they require in the moment, and if they have a non-zero remuneration you're willing to accept for them.
I would argue that anyone would accept unpaid volunteer work from the best minds in a given field. Starting from that assumption and working backwards is how I arrive at the original assertion.
The "almost" part is aimed primarily at regulatory limitations where volunteer work is forbidden by law.
I would argue that anyone would accept unpaid volunteer work from the best minds in a given field. Starting from that assumption and working backwards is how I arrive at the original assertion.
The "almost" part is aimed primarily at regulatory limitations where volunteer work is forbidden by law.
Not just volunteer work may be forbidden. There is also minimum wages among a large number of laws you have to abide in order to legally maintain any employee, and probably even more if they are overseas like I am. Some employers may also be morally impeded or wary of social consequences of "exploiting" workers even if they agree to it.
Both parties must actively want the other's offerings for work to make sense. If they say they are not hiring, there's no point checking any further whether this may be the case.
Both parties must actively want the other's offerings for work to make sense. If they say they are not hiring, there's no point checking any further whether this may be the case.
we're hiring for this kind of work if you want to chat :-) boris at getcensus dot com
Where screen scraping is concerned, do you have any thoughts on the risk of it turning into an arms race between you and companies with valuable customers as they try to prevent you from making migrations (to them, poaching their customers) easier? - e.g. They make it hard to scrape by deliberately and systematically changing their pages frequently forcing you to adapt regularly.
It strikes me as though the economics of this are not in your favour as a particular company only has to worry about their own site, but for your business model you potentially have to fight a war on many fronts to keep your service valuable and functioning.
It strikes me as though the economics of this are not in your favour as a particular company only has to worry about their own site, but for your business model you potentially have to fight a war on many fronts to keep your service valuable and functioning.
I have personally witnessed data migration multiple times from the consulting side. There is a reason consulting companies charge what they charge. Migration is generally messy, require understanding your customer domain and generally goes hand in hand with other business transformation. In my experience, the pain points are rarely the technical part of the migration.
Reading your pitch you seem to think you will be able to be cheaper by building a set of tools around the technical part. Do you intend to also deliver the other services a consulting company offer or do you see yourself as a potential service provider for these consulting companies?
Reading your pitch you seem to think you will be able to be cheaper by building a set of tools around the technical part. Do you intend to also deliver the other services a consulting company offer or do you see yourself as a potential service provider for these consulting companies?
We've spoken with consultants who are interested in our tools as a way to decrease the amount of effort required on their end to perform migrations (for example, so they can increase throughput and take on more customers.) Also, if a consultant is unfamiliar with the original platform, we help them get the data so they can apply their expertise to mapping it to the destination.
I think you might be rather successful in gaining initial market traction by scraping off sites which are closing down. This way, you will also be able to support people who would potentially be loosing a lot of their data otherwise.
Yes! This was the reason our first integration was with Chartio. I wonder if it is easy to find companies that are shutting down - maybe even an HN search would give us some direction.
Join Archive Team [1]! As that site says, "Archive Team is a loose collective of rogue archivists, programmers, writers and loudmouths dedicated to saving our digital heritage". We have a number of volunteers actively monitoring various sites and searching for others that are shutting down (there's a lot), which are noted on the Deathwatch [2].
Typically the process is as follows:
1. A site announces it is shutting down.
2. Archive Team discovers the site is closing and adds it to the Deathwatch.
3. Members of Archive Team collaborate to write scripts to extract user data from the website, using an existing archiving framework [3] developed for / by Archive Team.
4. Members of the public are invited to run instances of the archiving software [4], resulting in a distributed archiving network. This is often quite powerful, and has to be managed carefully to avoid overloading the site being archived.
5. Once completed, the data is (in many cases) uploaded to the Internet Archive to be stored permanently. Note that Archive Team is not affiliated with the Internet Archive, although we greatly appreciate their willingness to host this sort of data.
I'm not particularly actively involved with Archive Team at the moment (too busy with real life!) but I was heavily involved with a few projects, the most significant being the project to archive Yahoo Groups in 2019, which was quite complex due to the site structure (and Yahoo being less than helpful [5]). We got a lot (much more than I ever expected to get) but the majority of all that data was deleted.
[1] http://wiki.archiveteam.org/
[2] http://wiki.archiveteam.org/index.php/Deathwatch
[3] http://wiki.archiveteam.org/index.php/Dev/Seesaw
[4] http://wiki.archiveteam.org/index.php/ArchiveTeam_Warrior
[5] https://arstechnica.com/tech-policy/2019/12/verizon-reported...
Typically the process is as follows:
1. A site announces it is shutting down.
2. Archive Team discovers the site is closing and adds it to the Deathwatch.
3. Members of Archive Team collaborate to write scripts to extract user data from the website, using an existing archiving framework [3] developed for / by Archive Team.
4. Members of the public are invited to run instances of the archiving software [4], resulting in a distributed archiving network. This is often quite powerful, and has to be managed carefully to avoid overloading the site being archived.
5. Once completed, the data is (in many cases) uploaded to the Internet Archive to be stored permanently. Note that Archive Team is not affiliated with the Internet Archive, although we greatly appreciate their willingness to host this sort of data.
I'm not particularly actively involved with Archive Team at the moment (too busy with real life!) but I was heavily involved with a few projects, the most significant being the project to archive Yahoo Groups in 2019, which was quite complex due to the site structure (and Yahoo being less than helpful [5]). We got a lot (much more than I ever expected to get) but the majority of all that data was deleted.
[1] http://wiki.archiveteam.org/
[2] http://wiki.archiveteam.org/index.php/Deathwatch
[3] http://wiki.archiveteam.org/index.php/Dev/Seesaw
[4] http://wiki.archiveteam.org/index.php/ArchiveTeam_Warrior
[5] https://arstechnica.com/tech-policy/2019/12/verizon-reported...
My first instinct is to develop a Hotswap unified schema, something like (https://cloudinformationmodel.org/cim-model/) and then develop bidirectional mappings to particular services. Then transformation is a repeatable {Saas pool} -> Unified model -> {Saas pool} transformation. My second instinct is to reconsider the over engineered mess my first instinct came up with. Good job on getting to the point and having things work. Looks like a cool offering, good luck with it!
Thank you for the encouragement! We think a lot about this problem as well. We think that within a specific vertical ("productivity tools", "finance software") there is probably a lot of opportunity to use an intermediate schema for a bidirectional mapping.
But, as you mention, we're also being careful to observe what kinds of integrations customers are asking for before trying to generalize the problem.
But, as you mention, we're also being careful to observe what kinds of integrations customers are asking for before trying to generalize the problem.
Just thinking about the problem some more (from the perspective of the data owner), I wonder if instead of solving the problem at migration time the problem could be solved at the time of data creation.
What if data was routed to a) the Saas tool and b) to long term storage. So the act of migration becomes an act of moving raw historical data to the new tool instead of pull from service, transform and push to new service.
Oh, I think I just described a data lake..
What if data was routed to a) the Saas tool and b) to long term storage. So the act of migration becomes an act of moving raw historical data to the new tool instead of pull from service, transform and push to new service.
Oh, I think I just described a data lake..
Made me think of https://schema.org/
Never used either while modelling professionally but I think CIM's focus is slightly more on interoperability while Schema.org's goal was on sharing semantics and metadata. Those goals have a lot of overlap and the projects also have common contributors. Not sure why both exist.
This is a great idea and concept but either has to be narrowed drastically in scope or grow to unsustainble levels.
When I first clicked in on this link I was thinking it would allow moving from AWS (for instance) to Azure (or any other vendor).
That is a truly hard problem to solve. I see that is not a good use case for this.
Thinking about going from SAP -> Oracle E-Business Suite (if that is what Oracle's name is now) is another hard problem and in general takes years.
It is not just moving data, but enormous amounts of logic / routines / rules that are not 1:1 mapppable.
Producing a solution that is repeatable enough to reuse would take years as well and in that time the products themselves will have shifted
Scaping is ok you can get information but the forms of the new ERP will again not be 1:1
Many many years ago I worked on a similar project to this. Migraitng one ERP system to another (not the players mention here. Both were fully on prem.
After beating our heads, the wall figuring it all out, we ended up going directly at the database of the source system. This is certainly -not. advisable, it is not supported and not documented.
I still have nightmares about sitting for weeks figuring out the schema to the extent we could get the data we wanted. That it was non intuitive is an understatement.
What we came up with would not be usable to sell to a different company that wanted to do the same migration. Though we cold give them a lot of hints on the data model.
This was all secret. Had the ERP vendor we were moving away from seen what we did they could be quite displeased.
I hope I will love to see where this ends up.
If you manage to solve it well there are containers of gold in your future. If you end up taking a year or more pre major project then probably not as profitable and higher risk
When I first clicked in on this link I was thinking it would allow moving from AWS (for instance) to Azure (or any other vendor).
That is a truly hard problem to solve. I see that is not a good use case for this.
Thinking about going from SAP -> Oracle E-Business Suite (if that is what Oracle's name is now) is another hard problem and in general takes years.
It is not just moving data, but enormous amounts of logic / routines / rules that are not 1:1 mapppable.
Producing a solution that is repeatable enough to reuse would take years as well and in that time the products themselves will have shifted
Scaping is ok you can get information but the forms of the new ERP will again not be 1:1
Many many years ago I worked on a similar project to this. Migraitng one ERP system to another (not the players mention here. Both were fully on prem.
After beating our heads, the wall figuring it all out, we ended up going directly at the database of the source system. This is certainly -not. advisable, it is not supported and not documented.
I still have nightmares about sitting for weeks figuring out the schema to the extent we could get the data we wanted. That it was non intuitive is an understatement.
What we came up with would not be usable to sell to a different company that wanted to do the same migration. Though we cold give them a lot of hints on the data model.
This was all secret. Had the ERP vendor we were moving away from seen what we did they could be quite displeased.
I hope I will love to see where this ends up.
If you manage to solve it well there are containers of gold in your future. If you end up taking a year or more pre major project then probably not as profitable and higher risk
Sorry for being a bit skeptical. At some stage I did a ton of very complex migrations for telecom industry. My then general feel was: sure, you can automate particular bits and pieces but in the end you will still be doing a lot of custom built transformations. After a while I stopped hoping and just wrote individual migration software for every project (reusing parts of course). Due to insane amount of data as it is often the case in Telecom I also often had to write that conversion software as multithread and distributed package so that it can be ran multiple times and tested in reasonable timeframe.
So I think what you do is already or will end up the same way and in the end it is just the same custom consultancy for data migration.
I could be wrong of course but all of the above comes from a practical experience in the field.
So I think what you do is already or will end up the same way and in the end it is just the same custom consultancy for data migration.
I could be wrong of course but all of the above comes from a practical experience in the field.
This is different, since you are migrating from specific, very large and established systems. Obviously it will be possible to automate it.
Love the idea! Yes there are challenges (ref: 'Embrace and extend') but there is a very clear value: both for end users (that ultimately drive value) and for paying companies (startups or other) that have have great new products but have to deal with a market in which 'the current generation' of products are used.
From a different angle (that you're probably already considering :-): What about SaaS companies that also want to give customers a smooth way out if they are not satisfied. I can imagine that there is value in having some sort of 'seal' that makes it clear that: yes you can get out of here if our product is not what you want it to be.
Final note: I just hope that we’re not going to end up in a situation where we need to do a “ReCaptcha” again after logging in because some SaaS, x, is wary of scrapes….
Good luck!
From a different angle (that you're probably already considering :-): What about SaaS companies that also want to give customers a smooth way out if they are not satisfied. I can imagine that there is value in having some sort of 'seal' that makes it clear that: yes you can get out of here if our product is not what you want it to be.
Final note: I just hope that we’re not going to end up in a situation where we need to do a “ReCaptcha” again after logging in because some SaaS, x, is wary of scrapes….
Good luck!
> Our two biggest competitors are internal development teams (who end up being stuck doing this kind of work) and consultants (who charge a ton of money.)
But this is still consultancy work, right? So the differentiator here is managing those integrations like a real software company and thus cutting costs?
But this is still consultancy work, right? So the differentiator here is managing those integrations like a real software company and thus cutting costs?
If Hotswap learns how to migrate from company/technology A for client B, they can save time when helping client C if they also need to migrate data from company/technology A
Same is true for any consultancy company, of course.
In my experience, working with consultancies, they are not engineering first organizations. They are business types who have bolted on engineering (think legacy automakers bolting together binned products), instead of organically turbocharging their growth through automation and software engineering best practices (think Tesla vertically integrating and "building the machine that builds the machine").
If you're an MBA or biz type, you want to be at the former. If you're an engineer, you want to be at the latter.
If you're an MBA or biz type, you want to be at the former. If you're an engineer, you want to be at the latter.
Why would it be consultancy? They only need to write e.g. the Wix-extraction code once hopefully, and then just run it for each new client. Seems very scalable.
Your product seems really interesting.
How do you manage cases like Cloudflare 429 or other bot blocking mechanisms? I'd imagine your business is at risk if your customers' competitors implement efficient ways to block bots/scrapers?
Anyway, congratz on the launch.
How do you manage cases like Cloudflare 429 or other bot blocking mechanisms? I'd imagine your business is at risk if your customers' competitors implement efficient ways to block bots/scrapers?
Anyway, congratz on the launch.
I wish there was something like this for banking, insurance or other financial products. What a pain in the butt to move to a new primary checking account, wait in a queue to talk to someone about canceling your insurance or to move an IRA or brokerage account.
I would love something like this for Spotify/Youtube Music/Apple Music
I would advise to stay away from the word 'steal' because of the negative connotations.
OT -- I've noticed this personally too. I like to say 'steal' talking about ideas or tools or projects and I've noticed a lot of people will have a visceral reaction. It's similar to when you refer to socially acceptable drugs (caffeine,nicotine)'drugs'
What part of the market are you targeting? Up market, I worry a lot of system integrations are too custom/modified to really scale an 'easy migration' tool. Think of ERP for the best example but I see this constantly in ecommerce and as headless/microservices become more mature it's only going to get worse.
I'm not clear if you're trying to build an SMB/mid market focused set of scalable migration tools that you either build yourself or have the first few customers offset the dev costs with services OR if you're building an enterprise service business where your scale with automation will be more limited but the TAM would be immensely higher.
I'm not clear if you're trying to build an SMB/mid market focused set of scalable migration tools that you either build yourself or have the first few customers offset the dev costs with services OR if you're building an enterprise service business where your scale with automation will be more limited but the TAM would be immensely higher.
Man, this is the definition of "do things that don't scale" but I love the idea. Best of luck!
I would love to hear more about the continuous automated testing aspect of it since I maintain a hundreds of scrapers and run into this problem quite often.
I would love to hear more about the continuous automated testing aspect of it since I maintain a hundreds of scrapers and run into this problem quite often.
Len here. Thanks for the support! We default to using APIs if they're available and only scrape when we need to. In our experience, mid-large sized SaaS companies limit breaking changes at the API level and their UIs are relatively stable. When I was at Okta, it only took a small team to manage 1000s of non-standard integrations.
[deleted]
This is great, I have been thinking of starting this startup but also knew I would never do it since I want to focus on my current one. Someone else doing it takes away the stress, I can just leave it to you!
That's pretty much a truism: data is all dirty. You spend more time (2x? 10x?) dealing with that, than dealing with the normal data.
My son has a startup. Its trying to collect certain datasets and organize them in a tool. But every dataset of this kind is dirty, in a different way. They identify unique assets with different identifiers, or a fingerprint, or nothing. Its crazy trying to eliminate duplicates, find references between or even simply import a dataset.
On the plus side,that's a barrier to entry for a product of this kind.
My son has a startup. Its trying to collect certain datasets and organize them in a tool. But every dataset of this kind is dirty, in a different way. They identify unique assets with different identifiers, or a fingerprint, or nothing. Its crazy trying to eliminate duplicates, find references between or even simply import a dataset.
On the plus side,that's a barrier to entry for a product of this kind.
>> "If there is a platform you want to steal customers from, please contact us!"
The sound of one thousand business development and growth representatives getting in contact with you.
The sound of one thousand business development and growth representatives getting in contact with you.
And if they put up the transfers they support, it really indicates who's trying to get new customers and who's just trying to hold on to what they have.
In healthy markets, I'd expect the export graph to become bidirectional quickly.
In healthy markets, I'd expect the export graph to become bidirectional quickly.
If you know any, we'd love an intro :)
I like the product, there's a large market for it.
I see it as another case of developed -> developing country labor arbitrage:
I imagine the work can be outsourced to IT people in India (or possibly another country), and accomplished using a variety of code & low-code tools such as using Zapier, MuleSoft, etc., right. And then the end product & process just needs to be managed & delivered by an American IT people.
I see it as another case of developed -> developing country labor arbitrage:
I imagine the work can be outsourced to IT people in India (or possibly another country), and accomplished using a variety of code & low-code tools such as using Zapier, MuleSoft, etc., right. And then the end product & process just needs to be managed & delivered by an American IT people.
I think this actually a great idea and there is a ton of opportunity here.
Software salesmen over hype their software with fancy presentations, and lo and behold companies are stuck with their shitty software and locked in because the migration is extremely painful.
If you actually make migrations painless and super efficient I think it would be good for all parties and solve a ton of endless time humanity spends on pointless migrations.
Software salesmen over hype their software with fancy presentations, and lo and behold companies are stuck with their shitty software and locked in because the migration is extremely painful.
If you actually make migrations painless and super efficient I think it would be good for all parties and solve a ton of endless time humanity spends on pointless migrations.
One of the use cases this would be great for is Identity vendors although I suspect it won't work. There's been a lot of people moving to services like Auth0 and Okta because doing identity is hard and not something that'll help your business in the long term.
Also, as someone who's been stuck working on these migrations before, they suck and I'd love if someone could do it at scale for less cost.
Also, as someone who's been stuck working on these migrations before, they suck and I'd love if someone could do it at scale for less cost.
[deleted]
Is every migration bespoke or are there elements that can be reused and therefore allow the company to achieve scale?
I’m wondering if you would be able to play a role in credit card number migrations? Definite pain point.
> We take the burden away by working with vendors directly to automate common migration flows.
To clarify, this refers only to vendors of the new app choice, right? That is, only getting data in, not out. Assuming old app vendors won't help migrate users away from their app.
To clarify, this refers only to vendors of the new app choice, right? That is, only getting data in, not out. Assuming old app vendors won't help migrate users away from their app.
From my point of view, it's a brilliant idea with huge potential! Even it's not sustainable in sense of customers, it's very great to build a "migration ecosystem" to get new customers with every new migration path.
Heh - feels like the real business model here should be charging SaaS services for a guarantee _not_ to exfiltrate their data. How much would Wix have to pay for a guarantee that you'll never migrate customers off of their platform?
Is your target customer software vendors or companies that use these software vendors?
Today, we've been mostly focused on software vendors, and providing the service of making it easier to move people onto their platforms.
However, there is nothing stopping us from selling our service directly to end-users (the code is the same), so that is something we're working on setting up.
However, there is nothing stopping us from selling our service directly to end-users (the code is the same), so that is something we're working on setting up.
I wish new applications from now on are file based, be it json, csv, xml, toml, html, yaml, md, etc for longevity. There are huge numbers of applications that don't need ACID and aggregation across organization.
Not a lawyer, but “steal customers from your competitors” is a really bad framing - see a recent discussion on how Google (or any big company, really) educated people to never use such words.
Love this idea! Clever to build up the repeated skills and software internally, and take cuts of the moat-margin other SaaS tools reap from switching costs.
Do you have a list of all the platforms that you support and when will you be self-serve?
No pricing page? :/
So, it isn't 'easily' after all...
Could you help move sellers from ebay?
tomlin(3)
We've built a lot of enterprise software and done a lot of painful migrations over the years. I (Jay) have managed engineering teams at Frame.io, Squarespace, and Rent the Runway. Len was an early employee at Okta. At every single company we've worked at, we've spent a lot of time doing painful migrations. At Rent the Runway, we migrated our warehouse from UPS to FedEx. We changed credit card processors. We migrated ERP systems. It always took a ton of time, was not career-building work, and consultants charged $250/hr or more. We also were often stuck using platforms that weren't optimal because it was so hard to move.
So we decided to solve this problem: make it easy to change vendors, and make it easy for new companies to be able to bring on new users by automating the process.
We are essentially an ETL for SaaS products. We figure out how to extract data from the old system, even if there is not a clean API to do so, and automate it. We then help transform that data into a format that you can load into the new system. Our product is not self-serve. Instead, we work with you to understand how data maps to your system and integrate that logic into our migration engine. We then provide a Plaid-like widget for your users to connect their old systems and migrate data.
This is difficult, not in the "computer science" sense but in the "data is messy" sense. If there isn't an API to extract data, then we end up doing a lot of screen scraping, and many companies don't want to take the risk of maintaining that kind of code because it can break.
Our two biggest competitors are internal development teams (who end up being stuck doing this kind of work) and consultants (who charge a ton of money.) We take the burden away by working with vendors directly to automate common migration flows. We don't mind building and maintaining a lot of smaller one-off type projects for our users, as we benefit by building a repertoire of supported platforms.
The fact that modern applications have moved to SPAs has made this work easier than in the past. Every website essentially exposes an API, so it is not as difficult to extract data as it used to be. Our software tends to be more shelf-stable than people expect. Think about tech companies you've worked at: how often do you actually "break" the website by completely breaking the data or the UI? Len has had experience managing these kinds of integrations at Okta, and by using continuous automated testing we're able to quickly identify and fix breakages.
Currently we export data from Chartio, since it is shutting down next year, and Wix. If there is a platform you want to steal customers from, please contact us! We're openly eliciting suggestions and continually adding new platforms.
We'd love to hear your stories about painful migration experiences. And if you're a business whose customers ask "how do I move my data from the old platform?" then we would be super interested to hear how you work with these folks today!