By Richard Scannell, CEO, RiverMeadow Software

One of the things I get asked about a lot is the size of the market for companies like RiverMeadow - if migration is a “one and done” problem and therefore a limited market size.  We have a number of different ways of deriving market size for RiverMeadow, all of which point to a market of about $2B annually in this space – not exactly irrelevant.  However, we believe the market, even at that size,  is limited today simply because of the limitations of the existing tools.  Today, migrations are difficult, risky and expensive – so people do them as infrequently as possible.  But, what if migrations were simple, risk free and really cheap – what might happen then?                                                      

People easily and intuitively use a file manager - dragging and dropping files from one location to another, without (technically) caring for whether the destination is locally attached or network attached, SCSI or FC, USB or EMC…  the operating system simply takes care of it for us.  Why then should the process of migrating servers from one environment to another be any different – why can’t I just drag a server out of AWS and drop it into a VMware environment, or from OpenStack to AWS, VMware to Azure, etc. etc.  Why does it need to be a science project requiring weeks of planning, preparation, tool selection, dry runs, backup plans, consultants, project managers and on and on…

The answer lies in the highly disjointed current state of the “art” – i.e. individual tools, that were built to solve individual issues.  Let me be clear, - RiverMeadow doesn’t deliver this migration utopia today, but everything we do is foundational to this vision – from being completely API driven, to SaaS delivered (nothing for the user to install), to completely secure, to extensible by the user to execute custom functionality.  Our product is built along three axes – sources & targets (the OS and Clouds we support), features & functions (enrichment of our users experience and capabilities) and ecosystem – expanding our capabilities thru integration with others.  If you’ve got 10 servers to move, it doesn’t matter much which tool you use – they’ll all do a reasonable job and if you have to “touch” each server once or twice in the process, it’s no big deal.  However, when you’ve got 10,000 servers to move – which tool you use matters a great deal.  The scale out nature of cloud will call for tools to have similar scale out and automated capabilities – so, should we be building a tool that just addresses the current market, or building a capability that remakes that market in support of the wider reality that is Cloud.  We’re banking on the latter – but we’d love your thoughts and feedback.