Of course, deploying thin client apps on the back end is no trivial task, so if your firm is not using the technology already, it's unlikely it will invest in it just for iPad (and future Android tablet) users.
The other option could be to use cloud-based apps, such as Google Docs. But probably not. Google Docs works poorly on an iPad, since you can't interact with the spreadsheet directly as you can on a PC. Instead, you have to click an Edit button for each row, whch opens windows for each cell that you then work on, and click Submit to update. Likewise, in a Drupal website editor, you can't use the rich text facilities, and instead have to contend with a big block of HTML code to write or edit. It's very tedious and difficult.
The culprit is incompatibility between Web apps and the iPad's mobile Safari browser, which doesn't support all HTML attributes such as
contenteditable that Web apps use to make fields directly accessible to users. Plus mobile Safari doesn't support Java, so Java Web clients won't work (most AJAX ones should, though). Another issue: Safari often refreshes your pages when you return to them after working on another Web page or going to another application, and that means any information you enter in forms-based Web pages is lost, making many forms-based Web "apps" unusable on an iPad. Until Apple makes the mobile Safari browser equal to desktop Safari, using cloud apps on the iPad will be a hit-or-miss proposition.
The iPad data-access issue
One real difference under the hood between most mobile OSes and desktop OSes is that mobile OSes aren't based on a file view of the world, as PCs are. On a PC, you navigate to a folder (directly or through a shortcut) then launch an application (directly or by opening an associated data file). Folders and files are universal, and apps can work with them across your PC and network, ignoring files in incompatible formats. In mobile, the view is app-centric, so you must start by launching an app, which then has access only to data (files) in its partition (or sandbox) on the mobile device. Sharing data among apps means the apps have to move the data between them directly or through an OS-level API.
That leaves three main ways to access data on an iPad: through email, through a cloud service such as Box.net or Dropbox, or through an app designed to be a file sharer via Wi-Fi (of which there are dozens for the iPad). That means you need to think differently about working with files. You don't have files on your iPad that any app can access. Instead, you have apps that may, but probably do not, share their data with other apps.
For most people, email and cloud storage services are the way to go to access files -- though it means having to remember to send the attachment or load it to the cloud service from your PC before you head out with just your iPad. The Wi-Fi file-sharing apps do work, but both the iPad and the PC have to be on the same wireless network, and that may be an issue in many corporate environments that use firewalls, virtual LANs, and the like.
More and more apps support the iPad iOS' Open In facility, which lets them register as compatible with certain file types. Apps such as the built-in Mail client then check that registry and, when you tap a file attachment, provide a list of compatible apps to open the attachment in. Quickoffice and Documents to Go both do that, for example. Many apps still don't, but that will change over time.