Launch HN: Hotswap (YC S21) – Easily migrate customers away from competitors
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!
162 comments
[ 3.7 ms ] story [ 223 ms ] threadThis 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.
It is true that we have been marketing to vendors. That has been our method for prioritizing which scrapers to write.
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?
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!
>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!"
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 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.
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.
This would break any modern SaaS TOS I've ever read, I don't even think that's in question. Will Google allow you to transfer your data through an API, while connected to another service that is not authorized to use your account? Did anyone think this through, or ever read a TOS made after 2004?
We're like 1 step away from seriously entertaining a Kylie Jenner-endorsed SaaS. I think this community needs some self-reflection time. I'd rather not be tied to a community that creates the next economic collapse, byway of boosting untenable ideas. I remember arguing this point when Color was "the next big thing", and being downvoted for that opinion, too, but objective truth tends to get downvoted among intellectuals today.
> That's essentially what this is.
No.
https://news.ycombinator.com/newsguidelines.html
As for the topic - thoughtful critique is welcome but you're not really doing that. I'm a bit perplexed why this startup, of all startups, is the one that set you off, but ok - we all go on tilt sometimes. Still, please follow the site guidelines.
Edit: here's an example of what I mean by thoughtful critique: https://news.ycombinator.com/item?id=28327948. That commenter is bringing up what (I think?) is the same point you're objecting to ("do you think vendors won’t do everything to make your access more difficult or cut you off completely"), but it's a fine comment and obviously part of curious conversation, which is what HN threads are for. If you could comment more like that, we'd appreciate it. If you can't or don't want to, that's fine, but then please don't post.
Boosting false business is not acceptable in society. It shouldn't be here. And if that offends you so much where you need to ban me, then you've proven my point exactly. As a member of society, and a member of this community, I'm frankly getting sick of watching this community boost nonsense. Remember Color? What good reason did this community have for pushing that? Why is it /still/ pushing concepts as empty as that one was in 2021? Read up on the damage that boasting bad business does to communities, families, the economy. Putting light on that is not "attacking users." Being banned, or muted on a platform that's trying to re-imagine another economic meltdown is OK by me, just in case you need to know.
If this was a MLM, we could just label it and be done with it. Instead, what we have are an increasing number of businesses with huge floors that give way under the smallest bit of scrutiny. This sort of dialog - the one where you say I'm out of line for suggesting that economic collapses begin and end on this negative feedback loop of – is – let's face it – the same sort of mentality as the economic collapse of 2008. The wall street execs that peddled garbage at society's cost - they too thought they were doing god's work. Subprime mortgages. Impossible data transfer services that rely on your service having access to TOS-breaking APIs, balanced on seed money. Different branding. Same end result.
We'll leave it at that.
The moderation issue is simply that you're not allowed to break the site guidelines like that. It has nothing to do with your opinions about business or anything else.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
noun noun: attack; plural noun: attacks an aggressive and violent action against a person or place. "he was killed in an attack on a checkpoint"
Plainly, you don’t want me criticizing a YC startup. I can do a search on this site and find far more « attacking », difference being that those comments aren’t directed towards YC start ups. Plainly.
People criticize YC startups on HN every day. Just look at the beating these guys took in their launch post: https://news.ycombinator.com/item?id=28247379.
No objective reader would look at https://news.ycombinator.com/item?id=28328010 and see anything other than an insult. No more of this, please.
I really don’t know what you are alluding to here.
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.
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.
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!
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.
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!
Also, I may be misunderstanding your current offering.
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.
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.)
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...
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!
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 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.
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.
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.
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.
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..
"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.
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.
No it's not! Most people using Wix have no idea they will ever NEED to export their data. Call it user ignorance.
(Not disputing your assessment myself)
https://noyb.eu/en/exercise-your-rights-article-20-transfer-...
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’); [..]
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.
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.
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.
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.
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!
re: sensitive data - we provide an on-prem solution when an NDA or our TOS is insufficient
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.
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!