Wine is different from VMWare, Win4Lin, or Microsoft Terminal Services because it is 100% free software. That makes it an appropriate way to reach cost-sensitive market segments that do not wish to purchase commercial emulators, copies of Windows, or Client Access Licenses (CALs) for their Linux workstations.
Wine is fully commercially supported. You or your customers can purchase porting services or support from a number of providers.
Wine can run many Windows applications unchanged on Linux. The user runs the same installer, and the application feels just like it does under Windows. Thus your support costs are kept to a minimum -- you don't even need to rewrite your product's documentation.
Wine supports the Win16 and Win32 apis, so it can run many programs written in C, C++, Visual Basic 4/5/6, Delphi, Visual Fox Pro, etc. It supports popular Microsoft toolkits like ATL, WTL, and MFC. It does not support Microsoft.NET yet, so if your app is written in VB.Net or C#, Wine can't run it yet. (Another porting option is Mono, but it also has limitations at the moment).
Wine itself does not include or require any files from Microsoft. Your Windows app, if it was written in a Microsoft programming language, should include and install the language's redistributable runtime libraries. This is standard practice in the Windows world, and ensures your application can run on the widest possible variety of client operating systems. See for example Microsoft Visual Studio 6's EULA.TXT and REDIST.TXT which make it clear this is allowed without regard for whether your customers run Microsoft Windows or some other operating system. (Other versions are more restrictive; see the Visual C++ Toolkit 2003 EULA or the Visual C++ 2005 Express EULA. Consult the EULA.TXT and REDIST.TXT that came with your copy of Visual Basic or Visual C++ for details - yours may differ from the one I link to.)
That said, Wine now comes with implementations of many of the runtime libraries, so your app might work even if it doesn't bundle them.
Wine isn't just for Linux; it runs on several flavors of Unix on Intel, most notably Mac OS X for Intel. Porting to Linux via Wine can help extend your applications' market to just about every Intel-based desktop in the world.
It is likely that your application will expose flaws in Wine. The key to success here is to work with the Wine community to help them fix the problems exposed by your application. There are many ways you can help. Here are a few:
Gupta supports Team Developer on Linux using Wine. (See also their announcement, a distributor's page, and the Enterprise Times article.) Gupta chose to partner with Codeweavers to produce the Wine portion of this product, and has arranged for major Linux distributions (RedHat, Suse) to explicitly support Team Developer on Wine.
Bricscad is a commercial CAD application available for Linux. The documentation mentions that the application is built using winelib, and the user must separately install an old version of wine, though, which has led to user confusion. The problem should be easy to resolve - see the next case study. (Lesson: ISVs should use wine rather than winelib unless they need to target non-x86 platforms; not only does this let users try newer versions of Wine, but it also lets the ISV ship a single binary for both Windows and x86 Linux.)
SynaptiCAD is a set of tools for digital logic designers. They used in-house expertise to port their application to Linux, Solaris, and HP-UX using Winelib. For more details, including how they got around problems interacting with the user's normal copy of Wine, see the article by Dan Notestein, SynaptiCAD's president and co-founder.
Applied Wave Research's Microwave Office is a CAD application for electrical engineers. This Newsforge article describes the approaches they considered before they decided to contract with Codeweavers, and how the port worked out.
In 2004, Advanced Chemistry Development announced that their ChemSketch software runs properly under Codeweavers' Crossover Wine.
In 2000, Codeweavers helped two big ISVs, Borland and MusicMatch, port their flagship programs (Delphi and MusicMatch Jukebox) to Linux using Wine. (See InfoWorld article about Borland's Kylix, LinuxPlanet review of Kylix, MusicMatch press release, LinuxPlanet review of MusicMatch.) Both projects were technical successes, but didn't take off in the market (perhaps 2000 was too early for desktop Linux).
Codeweavers has a number of case studies of large end user organizations using Wine to migrate desktops to Linux without the ISV's participation.
Tor Lillqvist wanted to be able to use Windows Photoshop plugins inside a graphics program called The Gimp. This wasn't hard on the Windows version of The Gimp -- he just wrote a Gimp plugin that loaded Photoshop plugins. And as it turned out, the solution for the Linux version of The Gimp was as easy as invoking Wine when starting the Photoshop plugins, thanks to the separate-process model used by Photoshop plugins. Details at Tor's page "PSPI: Running Photoshop plug-ins in GIMP. Now on Linux, too!" (Tor used Winelib for this, but I think Wine would have worked just as well.)