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.

‍