<img height="1" width="1" src="https://www.facebook.com/tr?id=730305433807073&amp;ev=PageView &amp;noscript=1">
Book a Demo

A Dirty Little Secret About InfoPath

The dirty little secret about InfoPath is that it’s still in widespread use. While sometimes it’s due to simple inertia or low budgets, at least as often the reason is more existential. For starters:

InfoPath was actually pretty good, and one big reason it’s still in widespread use is that almost nothing else has come close.

I’m not talking about its web/cloud architecture – that was indeed a mess. But in terms of suitability to business requirements? It was great. You could make it display/collect the data you wanted, the way you wanted it. It handled multiple pages, sections, and multiple master/detail relationships. While some things could have been easier, they were nevertheless achievable without code.

Most “InfoPath Replacements” out there are still missing key parts of InfoPath’s feature set. They might be optimized for mobile solutions and not take advantage of what’s possible in a full-sized display. They might be a framework for JavaScript code. They might require a ton of extra work (coding and/or clicking). They might be really expensive.

I obviously think skybow isn’t guilty of this – we genuinely implemented a way to do just about everything InfoPath does – and I’ll extend praise to one or two other companies as well. For most vendors, though, “InfoPath replacement” means “we do forms, too, but you’ll need to relax your requirements.”

For an innovation to be adopted over an existing option, at the very least it needs to provide a relative advantage over and be compatible what you want to replace (there are other criteria, but these two come first). We’ve already been talking about a lack of relative advantage, but the matter of compatibility brings us to the second big reason InfoPath remains in widespread use:

People can’t move away from InfoPath without a migration path.

Does it seem crazy to ask people to use your new product without offering them an option other than “rewrite everything?” I know, some say “use us for new work and leave the existing stuff in InfoPath”, but who finds that option comfortable, knowing that InfoPath’s days are numbered?

Well, that’s all a company can advocate if their feature set isn’t compatible enough to make migration possible. But if one can approach InfoPath’s feature set, migration becomes a moral obligation.

As you might guess, skybow takes that moral obligation seriously. We do indeed have an InfoPath migration story. We worked with our friends at Rencore to create it. Their SPTransformator locates and analyzes InfoPath forms, and we take the details of their analysis and use it to generate corresponding skybow Rich Forms.

We’re putting it through a lot of tests at the time of this writing and expect to release it shortly. If you’d like to know more www.infopath-replacement.com has a lot more detail on the subject. This is going to make being a skybow and Rencore customer make even more sense than it already does.


Mike Fitzmaurice

Written by Mike Fitzmaurice

Mike Fitzmaurice is skybow's Chief Technology Officer, and is a recognized thought leader in citizen development, workflow/business processes, and low-code/no-code solution platforms and strategies. Mike has more than 25 years of product, consulting, evangelism, engineering, and IT management expertise. He spent a decade at Microsoft and was the original technical product manager for SharePoint, helping launch and shepherd its first three releases; it was Mike who birthed, developed, and led developer evangelism on SharePoint, positioning it as a development platform. Other gigs included a decade at Nintex as Vice-President of Workflow and Product Technology and five years as Director of IT at the National Association of Broadcasters.