I work at a SOA shop (and we sell our own stack...perhaps you bought ours!), and it can really help businesses become more agile...if it's done well.
The problems come when:
People start making everything into a service, and you end up with just as many interconnections and interfaces as you had before you inserted an ESB. This makes change very difficult.
If you're using BPM with human interfaces: people don't 'get' portlets. Instead of making individual portlets do one task each, they make them do lots of things, which defeats the object of BPM. I can expand on this lots if necessary, but this might not be relevant to you.
It's all implemented at once. It's a massive system change, so try and do it slice by slice. (for example: just front your existing systems with web services, and build a new UI on top. Then gradually replace the UI calls that went to the old system with ones to the new system.) This will aid user acceptance as well as be a much safer way to do things. Management possibly won't want this approach (it's harder to manage) but emphasise the benefits. A lot.
It's sold as codeless development. This doesn't exist, and probably never will. Even if you don't have to write any code, if you don't know how code works then yours will be incomplete, ill-thought-out or unmaintainable.
From what I've seen, if SOA's done well then your business can turn on a sixpence, and it's cool. If it's done badly then it probably won't be worse than your legacy system, but it won't be better, and you'll have had an expensive and painful time in between for nothing.
I could give you a customer list but I dunno if I should, so I'll leave it. Suffice it to say we have some massive, everyday brandnames using our stack end to end.