FWIW, both mycompany.com.au and ourcompany.com.au are real and registered domains; I'll presume they're not the domains you're migrating from or to. Accordingly, I'll use example.org for your old stuff, and example.com for your new stuff; the example domains are RFC-reserved for this usage.
First off, if at all possible, ignore the rebranding and use the old example.org domain inside your network. That will have (technical) advantages. (And no, potentially peeving the marketing folks that came up with the example.com rebranding is not considered one of those advantages.)
Each host should have one A record (and one AAAA record, if you have IPv6 active), and one of the more common errors in these migrations is setting up an A record for each new domain that might arrive; each host has one A (and possibly one AAAA) record, and that's the canonical name for that host. Externally, that'll probably be the latest name in any sequence (such as www.example.com), and all previous names (including www.example.org) will have CNAME entries.
Internally (and here's why having a different domain inside is handy) use one of the old names; use example.org, for instance. This means you can use the public DNS services for the external web sites and resources; your internal DNS servers receive the requests for example.com hosts and go "duh, lemme ask somebody else for that", and that somebody else is the (public) DNS server your external DNS services for example.com hosts.
The usual trigger for not reaching the external A (or AAAA) records is either a stale cache on the particular client (for translations inside the Time To Live (TTL) values for the old DNS translations, or pending a local cache flush on each client), or (and this is more common) confusion over authoritative DNS servers; you have your internal DNS configured as authoritative for the new www.example.com domain, and also authoritative for the old www.example.org domain, and your external DNS is also authoritative for (probably) both domains. Internal requests get as far as the internal server, and get an authoritative translation (possibly being "no such host"), and don't go any further.
If your internal servers are authoritative for example.com hosts, then you'll need to duplicate the external IP addresses in your internal DNS; you'll basically have to mirror parts (or all) of your external DNS translations. (This part of is why I'm fond of separate DNS domains (or a DNS domain and subdomain) for internal and external hosts; it means I need only have one copy of the IP translations, and I don't need to keep the internal DNS in sync with the external DNS.)
The single A (and possibly one AAA) record stuff for the host tends to be particularly enforced by other mail servers too, so if you're hosting your mail on these same servers, then the DNS translations for that mail server needs to be correct. That is, one A (and possibly one AAAA) record for the host, which means the forward and reverse translations will match. If you have more than one A (or AAAA) record, the names won't match, and other mail servers will assume your mail server is a spam engine.
In general, you should not be allowing zone transfers from your internal DNS servers originating from outside of your network.
Here's a long-form write-up on configuring DNS on OS X Server.
