Seems like what you need to do comes down to normalizing the data structure, and simply put ['company'][$id] in front of every $array use. You could of course use find & replace (with a tool like AstroGrep), but.. Time for some terminology.

Refactoring.

Refactor first so you can warp your head around it more easily, basically restructuring the problem so its very simple to solve, then just bolt on the new functionality.

Refactoring is changing the internal codebase design to better match (new) demands. Be it performance, stability, or even readability. Adding/changing functionality could be put under the same umbrella but i would not: usually this is the thing one bolts on in a few minutes after the refactoring.

An example..

So when i refactor i do not change any functionality, i just make a place where i can easily bolt on some, at a later time. All functionality is kept identical.

I would have all lookups in that array go through a central place, a function like:

/**
 * Central customers lookup method, to aid implementing future functionality.
 * @param array $array       The original array.
 * @param Integer $companyid Optional. If given $array['company'][$companyid] must exist.
 * @return array             The $array parameter or a subset thereof.
 */
function GetCompanyCustomers($array, $companyid=null) {
  if ($companyid==null) {
    // Old approach
    return $array;
  } else {
    // Example doublechecks for debugging
    if (!isset($array['company'])) {
      echo 'Error! GetCompanyCustomers() $array["company"] does not exist.';
    }
    if (!isset($array['company'][$companyid])) {
      echo 'Error! GetCompanyCustomers() $array["company"][$companyid] does not exist.';
    }

    // New approach
    return $array['company'][$companyid];
  }
}

This facilitates the transition.

First you inject this function (and a setter, perhaps) everywhere and make sure that everything works exactly as before, then you switch to actually using $companyid. Even undoing your changes should be easy, just alter the function again. Consider making matching setter(s).

Further advise:

Its usually not a good idea to have a array that big that contains all data, that is filled again per browser request. It exposes a fundamental bad design. Unless you have to show all that data at once on one page.

Keep in mind to have your data normalized so that parts of the hiearchy are self-describing, self-contained. Use data models to fence off external access, a array may be efficient sometimes but it can bite you especially in an untyped language like PHP. What i did now with the getter could (or should..) be put in a (DataModel representing) class.

It looks like ArrayObject in PHP5 will allow you to create a custom class which can operate as an array, which would allow you to do horrible, horrible things such as [$foo] returning totally different things depending on context. It may not be a good idea, but I don’t see why you wouldn’t be able to give a smarter data access object the same interface as an array and thus have it be a drop-in replacement. At least if you are accessing based on constant strings then you should be able to change behavior with a minimum of unnecessary astonishment.