[HN Gopher] Launch HN: Hotswap (YC S21) - Easily migrate custome...
___________________________________________________________________
Launch HN: Hotswap (YC S21) - Easily migrate customers away from
competitors
Hi! We're Jay and Len (kevlened) from Hotswap
(https://www.hotswap.app). We automate the process of changing
software vendors by helping you migrate user data during your
onboarding process. In other words, we make it easy to steal
customers from your 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!
Author : memset
Score : 251 points
Date : 2021-08-27 13:39 UTC (9 hours ago)
| FpUser wrote:
| 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.
| Grustaf wrote:
| This is different, since you are migrating from specific, very
| large and established systems. Obviously it will be possible to
| automate it.
| tsthename wrote:
| 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!
| dorianmariefr wrote:
| Made me think of https://schema.org/
| tsthename wrote:
| 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.
| memset wrote:
| 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.
| tsthename wrote:
| 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..
| vlovich123 wrote:
| 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.
| zerkten wrote:
| 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.
| irq-1 wrote:
| > 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.)
| memset wrote:
| 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!
| [deleted]
| sillysaurusx wrote:
| 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!
| d0gbread wrote:
| 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.
| a13n wrote:
| No pricing page? :/
| adamc wrote:
| As someone who has been through a long, complex migration... very
| interesting company idea! Kudos.
| memset wrote:
| Thank you! You've piqued my curiosity: are there any migrations
| that have been _particularly_ painful for you? (Where might we
| have been able to help? What made them painful?)
| meterplech wrote:
| 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.
| tyingq wrote:
| 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.
| memset wrote:
| 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.
| TedDoesntTalk wrote:
| > 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.
| Cthulhu_ wrote:
| 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.
| sleepyhead wrote:
| 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.
| chmod775 wrote:
| 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');
| [..]
| rgj wrote:
| 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/
| ldoughty wrote:
| Not a lawyer, but my business doesn't sound like a
| identifiable natural person...
| siva7 wrote:
| I beg to differ. There is almost no legal business with
| paying customers that wouldn't fit under these criteria
| chmod775 wrote:
| 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.
| tyingq wrote:
| 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.
| p49k wrote:
| That's not compliant with GDPR, then.
| tyingq wrote:
| They seem to think it is:
| https://support.wix.com/en/article/gdpr-deleting-and-
| restori...
|
| (Not disputing your assessment myself)
| toomuchtodo wrote:
| 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-...
| TedDoesntTalk wrote:
| Wix! Take note! Some guy on the internet says you are legally
| obligated to provide data export!
| [deleted]
| TedDoesntTalk wrote:
| Wix! Take note! Some guy on the internet says you are legally
| obligated to provide data export! :)
| [deleted]
| jacquesm wrote:
| I would advise to stay away from the word 'steal' because of the
| negative connotations.
| pwillia7 wrote:
| 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'
| gjvr wrote:
| 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!
| pwillia7 wrote:
| 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.
| jabo wrote:
| Is your target customer software vendors or companies that use
| these software vendors?
| memset wrote:
| 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.
| vtail wrote:
| 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.
| WastingMyTime89 wrote:
| 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?
| memset wrote:
| 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.
| rubyfan wrote:
| 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.
| JoeSloth wrote:
| I would love something like this for Spotify/Youtube
| Music/Apple Music
| mynameismon wrote:
| 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.
| memset wrote:
| 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.
| betamaxthetape wrote:
| 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...
| neximo64 wrote:
| How much data can you do can you do it all? What about semi
| locked platforms like marketo?
| kevlened wrote:
| If you can see it as a user, we can get it. If you'd like to
| migrate from marketo, let's chat :)
| bacheson1293 wrote:
| 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!
| MathYouF wrote:
| 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?
| weird-eye-issue wrote:
| 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?
| ManBlanket wrote:
| 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.
| 666b20753a29 wrote:
| What does ESL mean? I can't seem to infer it
| nix0n wrote:
| English as a Second Language
| KuzMenachem wrote:
| English as a second language I presume
| Corrado wrote:
| English as a Second Language
| mbesto wrote:
| 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.
| kevlened wrote:
| 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.
| reilly3000 wrote:
| 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!
| 58x14 wrote:
| 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.
| lallysingh wrote:
| 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.
| kevlened wrote:
| 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
| reilly3000 wrote:
| 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.
| kevlened wrote:
| 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.
| [deleted]
| Grustaf wrote:
| 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!
| tgtweak wrote:
| 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.
| MattGaiser wrote:
| Do you fear an arms race of sorts if this becomes big? Someone
| founds StopSwap to randomize APIs?
| mometsi wrote:
| "There is another theory which states that this has already
| happened."
| kevlened wrote:
| 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]
| josephwegner wrote:
| 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?
| mlvljr wrote:
| Anyone pulled a meta on you yet?
| brtknr wrote:
| Is every migration bespoke or are there elements that can be
| reused and therefore allow the company to achieve scale?
| StratusBen wrote:
| >> "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.
| lallysingh wrote:
| 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.
| memset wrote:
| If you know any, we'd love an intro :)
| JoeAltmaier wrote:
| 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.
| boplicity wrote:
| 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.
| woodrowbarlow wrote:
| 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).
| memset wrote:
| 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.
| [deleted]
| memset wrote:
| 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?
| lkbm wrote:
| 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!
| mariushn wrote:
| > 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.
| easton wrote:
| 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!
| kevlened wrote:
| 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.
| rstupek wrote:
| Why is Wix one of the two you initially support?
| memset wrote:
| We had a customer who runs a platform for fitness instructors
| (to sell their videos, classes, etc) and their users already
| had all of their content on Wix.
| villasv wrote:
| > 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?
| Grustaf wrote:
| 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.
| conradev wrote:
| 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
| villasv wrote:
| Same is true for any consultancy company, of course.
| toomuchtodo wrote:
| 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.
| llaolleh wrote:
| 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.
| betamaxthetape wrote:
| 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.
| toomuchtodo wrote:
| 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).
| codingdave wrote:
| 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!
| aeoleonn wrote:
| 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.
| picodguyo wrote:
| 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!"
| lvass wrote:
| I actually enjoy this kind of work. Wonder if they're hiring.
| cheschire wrote:
| 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.
| lvass wrote:
| 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.
| borisjabes wrote:
| we're hiring for this kind of work if you want to chat :-)
| boris at getcensus dot com
| MattGaiser wrote:
| 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.
| khaki54 wrote:
| 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!
| memset wrote:
| 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?
| whelchel wrote:
| 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.
| config_yml wrote:
| 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.
| memset wrote:
| 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.
| tomlin wrote:
| This site has become a bit of circle jerk of honestly the worst
| kind of manufactured promises and "signal boosting to success
| regardless of merit."
|
| 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.
| MarcelOlsz wrote:
| What do you mean? I don't understand your comment.
| tomlin wrote:
| Do you think a project, which absolutely requires
| participation (or at least en acquiesce the existence of this
| platform), is going to stick around? Do you think Wix is
| going to be cool with a system built around pulling customers
| away? If so, why? Cause I read the site and I don't read how
| that huge problem is melted away.
| post-it wrote:
| Some things are worth doing even if they're hard.
| tomlin wrote:
| A lot of things are - but this requires active
| participation of competitors. Imagine starting a company
| that allows users to identify homes they like, and then
| an entire apparatus kicks in to kick the current people
| out of the house, cancel all of the bills, transfer
| everything to you, all the while - no one complaining,
| filing a lawsuit, never calling the police while they are
| being evicted. That's essentially what this is. How are
| you going to get Google to be okay that you're
| transferring everything from them, to Amazon, through an
| API connection that 100% would violate any modern TOS? I
| just don't get you, dude.
| MarcelOlsz wrote:
| I think it's a great idea if its executed well. Don't see
| anything wrong with the OP, I'd use it if it was fleshed
| out. For example if I wanted to migrate from firebase to
| some other service, this would be valuable.
| tomlin wrote:
| So you think that Google would go through all the trouble
| of preventing screen-scraping on all of their platforms,
| but wouldn't prevent activity on their APIs coming from
| transfer.hotswap.com? Cool. I just wanted to absorb your
| sense of reality.
| xvector wrote:
| Eh, this looks like a pretty cool effort imo
| tomlin wrote:
| Do a second of objective thought.
| dang wrote:
| Hey - you're seriously breaking the site guidelines here by
| attacking other users. Not cool, please stop.
|
| 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.
| wodenokoto wrote:
| Is Jay some sort of former Olympic athlete? If so I fail to see
| it as part of this startups promotion.
|
| I really don't know what you are alluding to here.
| tomlin wrote:
| I'm alluding that this..."fan base" will love anything with
| the letters "YC S*" in it, even if it's DOA.
| davewritescode wrote:
| 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.
| wallawe wrote:
| 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.
| kevlened wrote:
| 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.
___________________________________________________________________
(page generated 2021-08-27 23:00 UTC)